Gnome terminal scrollbars background is not themable

The scrollbar background color can't be changed, as

In ubuntu we use scrollbars that are partially transparent, and it's not possible to do this in the terminal since the scrollbar is a widget boxed next to the terminal screen, but that doesn't inherit the terminal color (see issue at http://i.imgur.com/qBxFYQr.png).

Proposed fix for this is at https://git.gnome.org/browse/gnome-terminal/log/?h=scrollbar-bg-fix

I've added an extra box, as I guess it might count in case semi-transparent backgrounds will be supported. As for now, setting the BG on both the main hbox or in a sub-box is just the same.

Created attachment 311016
TerminalScreen: add bg-color and fg-color properties

And relative getters.

Created attachment 311017
TerminalScreenContainer: use the screen background color for main hbox bg

The hbox that contains the terminal screen and the scrollbar should have
the same background color of the terminal screen.

Created attachment 311018
TerminalScreenContainer: move scrollbar inside a box and just theme that

In this way the background doesn't apply to the full main hbox, at the
current state this doesn't change much, but I guess it might in case of
semi-transparent backgrounds.

This is basically temporary solution until bug #733210 is not properly fixed.

I'm also using Ubuntu's default desktop and I don't face this problem. The scrollbar looks as you'd expect without any patch.

Maybe you're already on Wily alpha and something changed there? I recall they were about to drop their overlay scrollbar and replace with something new from mainstream Gtk+.

Wouldn't these patches break the look on systems using old-style scrollbars?

Recently there were some debates and several tickets whether the chrome (notebook tabs etc.) should match the desktop's Gtk+ theme or the terminal's color scheme, and the conclusion was to match the Gtk+ theme. On one hand, I wouldn't be too keen on starting that debate all over again. On the other hand, I totally agree with you that your screenshot just doesn't look right.

Maybe it's time for Ubuntu to re-think their odd purple background for the terminal?? Maybe they should carry your patches downstream?? I'm really not sure... Maybe jump right into fixing that other bug; would that really eliminate this issue?

Created attachment 311022
Manually draw background under scrollbar

The issue is showing up when using this new theming [1]

> Wouldn't these patches break the look on systems using old-style scrollbars?

I don't think so, it's just about setting the background, which would be base_color instead. And that the theme can still override if needed.

I would be happy to fix the other bug also, but it seems something that could take longer time than we currently have (as per various freezes).

I come up with another solution btw, that also fixes the problem when the transparency patch (that Ubuntu ships) is available.

[1] https://code.launchpad.net/~3v1n0/ubuntu-themes/osd-scrollbars-improvements/+merge/269245

Comment 6 is right: chrome should look like chrome, not content. So the background colour isn't a problem, IMO.

The screenshot in comment 0 does certainly show a number of problems with ubuntu's scrollbars, i.e. lack of steppers and through.

Fixing bug 733210 (which will require work in gtk+) will fix your issue if you then switch to overlay scrollbars (which won't be the default in g-t, since it interferes with the terminal's working).

(In reply to Christian Persch from comment #8)

> which won't be the default in g-t,
> since it interferes with the terminal's working).

That's as easy as increasing the right padding of the widget. I wonder how come Ubuntu hasn't done this yet. And this automatically makes the unused bits of the scrollbar have the terminal's background (up to Vivid + overlay scrollbar; not sure about how it'll change with Wily).

E.g. I have this in ~/.config/gtk-3.0/gtk.css:
VteTerminal {
    padding: 1px 3px 1px 1px;
}

(In reply to Marco Trevisan (Treviño) from comment #7)

> (as per various freezes).

Given the unfortunate timing of Gnome vs. Ubuntu freezes, the earliest any fix can make it into Ubuntu via mainstream is Gnome 3.20 (spring '16) -> Ubuntu YY (autumn '16). (I assume it's quite a big change to be done within the 3.18 stable series.) So if it's broken now in Ubuntu, they'll have to patch it downstream in at least two consecutive releases, Wily and XX – and if they patch in in two releases, carrying that patch for a 3rd or 4th release doesn't necessarily sound much worse. So maybe we can just wait for the required Gtk+ feature and then have a proper solution??

(In reply to Christian Persch from comment #8)
> Comment 6 is right: chrome should look like chrome, not content. So the
> background colour isn't a problem, IMO.

Right, but in case you want your chrome to use a mix of your background colour (i.e. using alpha background on the scrollbar), this is not currently possible. Since the background color can't be changed from theming.

Also, I think apps should not care about what a theme wants to do. They should just allow it.

However, here's what we('ll) have https://transfer.sh/yS1Zs/out-18.ogv in regular gtk apps, and without this change this is not feasible with gnome-terminal.

(In reply to Egmont Koblinger from comment #10)
> So maybe we can just wait for the required Gtk+ feature and then
> have a proper solution??

Well, I see the point in doing that and that's fair from an upstream point of view.
I just pushed my solution, which I knew was a temporary one, as it might be useful for other downstreams.

(In reply to Christian Persch from comment #8)
> Fixing bug 733210 (which will require work in gtk+) will fix your issue if
> you then switch to overlay scrollbars (which won't be the default in g-t,
> since it interferes with the terminal's working).

Mh, actually I think that overlay scrollbars don't interfere with terminal, if they're implemented correctly. In other apps the space that is used by overlay scrollbars is still reserved for them, although they're not visible.

This doesn't seem to apply to terminal when using the patch attached to the issue you mentioned. So I think that's another element of the patch that needs some work, as "overlay" here doesn't mean that they will cover the content.

(In reply to Marco Trevisan (Treviño) from comment #13)

> Mh, actually I think that overlay scrollbars don't interfere with terminal,
> if they're implemented correctly. In other apps the space that is used by
> overlay scrollbars is still reserved for them, although they're not visible.

I don't think I'm following you. In the video you linked the scrollbar overlays the word "chaotic", just as in Ubuntu versions up to Vivid. What did conceptually change?

Are there perhaps several pixels reserved for the scrollbar only, and several other pixels as the overlay area?

(In reply to Egmont Koblinger from comment #14)
> I don't think I'm following you. In the video you linked the scrollbar
> overlays the word "chaotic", just as in Ubuntu versions up to Vivid. What
> did conceptually change?

That's because the view is not fully scrolled on the right, so it's normal that some content is covered. However when you move it fully to the right, no word is covered by the scrollbar.
Default gnome scrollbars (I mean using Adwaita theme) wouldn't do it either, but still are very close to the view (or word, in this case). In Ubuntu instead we've 2px as margin, that would avoid to have the scrollbars that begins as soon as the view is over (other than adding some proximity effect on mouse-enter as well).

> Are there perhaps several pixels reserved for the scrollbar only, and
> several other pixels as the overlay area?

In that video, the scrollbar is requiring 10px (so these are reserved to it), but when painting will use only 8px on mouse-over and 3px otherwise.

I see, thanks. ChPe is much more familiar with these kinds of Gtk+ things, but AFAIK he doesn't use Ubuntu. I'll upgrade to Wily when it's released and see if there's something I can do.

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 sc...

Based on Ambiance/gtk-3.0/gtk-widgets.css and apps/gnome-terminal.css, here's an example how to make the scrollbar narrower and not waste precious width:

~/.config/gtk-3.0/gtk.css:
TerminalScreenContainer .scrollbar {
    -GtkRange-slider-width: 3px;
    margin: 0;
}

Created attachment 312194
Screenshot: unpatched, somewhat ugly

Created attachment 312195
Screenshot: patched, really misleading

> > Comment 6 is right: chrome should look like chrome, not content. So the
> > background colour isn't a problem, IMO.
>
> Right, but in case you want your chrome to use a mix of your background
> colour (i.e. using alpha background on the scrollbar), this is not currently
> possible. Since the background color can't be changed from theming.
>
> Also, I think apps should not care about what a theme wants to do. They
> should just allow it.

I don't think just because a theme 'wants' to do something we should make it possible. More so since you cannot do that with any other widgets either, not just VteTerminal.

Fixing bug 733210 will allow you to enable real overlay scrollbars, which won't have the 'reserved space but there's nothing there' problem.

Meanwhile, the only problem I see in those last 2 screenshots is poor design of the theme's scrollbar.

WONTFIX as per comment 8 and 21 ?