Comment 19 for bug 1493964

I've upgraded to Wily beta and tried its g-t package (which contains your patch), followed by g-t from git (which does not contain it). I can indeed see the difference.

Current mainstream g-t looks ugly without that patch. There's a 10px wide gray column, within that the scrollbar occupies the rightmost 3 or 8 pixels depending on whether the mouse is over the scrollbar area, exactly as you said above. That is, it's 10px gray for the part where the draggable bar is not present; 7px gray + 3px orange normally for the bar itself; 2px gray + 8px orange on hover.

With your patch, on the other hand, while it's probably a bit less ugly, it actually introduces a severe usability problem. There are usually 8 or 10 pixels added to the right (in addition to vte's 1px padding) in exactly the same background color as the terminal. Combine this with a font that's a little bit smaller than Ubuntu's default, and it's already as wide as an entire character cell. (I, for one, use the "Monospace Regular 8" font which is 6x13 pixels, so it's ~1.5 cells wide.) Combine this with bash line editing where the command you're entering wraps one character before you'd expect it to wrap and you wonder why the last cell was skipped... or any fullscreen app, e.g. your favorite editor, vim, emacs, whatever, and again wonder why the last column is unused... or midnight commander that paints the whole screen with a nondefault color, yet leaves about one character column on the right unused. Of course it's not a character column but the scrollbar area, but it's terribly confusing.

I really liked the varying-width overlay scrollbar up to Vivid, as it didn't add anything to the window's width, and overlapped the characters a little bit when you actually used it. If, however, the entire width is reserved for the scrollbar only, I see no reason whatsoever for changing its width rather than having a fixed width. (Yes, I understand that if the content was scrollable horizontally, that area could be used to paint actual content. But in case of vte it's not scrollable horizontally, hence suddenly this whole design just doesn't make any sense.) Moreover, its background color really does need to be different from the terminal's.

And even if I accepted that the orange bar changes its width (despite the scrollbar widget having a dedicated width for its own use), I would still not see the always gray leftmost 2px justified.

The pretty usable Up/Down arrows are also gone.

It its current form, for a widget that's scrollable along one axis only, just as vte, it's nothing more than a really old-fashioned scrollbar, even lacking the Up/Down buttons, and having the most minimalistic design one could ever imagine.

The only advantage I can see over the previous overlay scrollbar is that that code contained several bugs and was unmaintained. Getting rid of that will allow me to address bug 709089. But the user experience is definitely worse, and having the same color background would make it even worse. Unless, of course, there's a way to make it actually an overlay scrollbar, one that steals pixels from vte's area on hover.

(While we're at it: is there any way to reduce the width of the scrollbar? Something to be put in gtk.css?)