GNOME Bugzilla – Bug 763007
Custom color for (extra) padding
Last modified: 2021-06-10 15:11:54 UTC
I'm wondering if we should introduce an option so that the extra amount of padding (that's there due to an unaligned window size) could have a different color from the terminal background. This would make it more obvious to the users that that's "unused" area, not available to the apps running inside the terminal, and would give a visual clue about the boundaries of the active area. This idea was inspired by: - the always reoccurring question from users why apps don't use the bottom line of fullscreen terminals (e.g. http://superuser.com/q/1039121/278816), - a recent change in Gtk+ (bug 760944) which makes me uncertain if geometry hints will work, - my opinion about this fear at bug 762956 comment 4, - tiling emulators like Terminator, Terminix that by design just can't set geometry hints in a way that'd make sense and need to have continuous resize, - a usability bug 754796 around the scrollbar, and Ubuntu applying the patch (https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1493964) despite my counter recommendations in the g-t bug comments 17-20.
Technical details: VTE: - Would this new color refer to the entire padding, or only for the extra padding (the one due to unaligned window size)? I'd vote for the latter, the standard 1px padding I'd like to remain the same as the terminal's background. - Does the extra padding go inside or outside of the normal padding? I think the normal padding should be inside, and the extra one should be outside. - Needs to support alpha channel. - For backwards compatibility, the extra padding would automatically have the same color as the background until it's explicitly set via the new API call for the first time in the widget's lifetime. From that point they live separate lives. This could be cleaned up the next time we break the API/ABI. - At the bottom, the extra padding would nicely scroll out if you slowly drag the scrollbar, thanks to the smooth scrolling feature. Gnome-terminal: - If colors are taken from the system theme, I think it should be the main color of the Gtk+ theme (according to the dark/light switch). - If colors are not taken from the system theme... then what? Do we want another (hard-to-explain) element on the profile prefs' Colors tab? Or just some magic and some underlying dconf variable? - When fullscreened, g-t could automatically set it to pitch black instead, and restore when unfullscreened. Is this a good idea?
(In reply to Egmont Koblinger from comment #1) > - Would this new color refer to the entire padding, or only for the extra > padding (the one due to unaligned window size)? I'd vote for the latter, the > standard 1px padding I'd like to remain the same as the terminal's > background. I agree that the standard padding should continue to be in terminal bg colour. > - Does the extra padding go inside or outside of the normal padding? I think > the normal padding should be inside, and the extra one should be outside. Yes, outside the standard padding. > - For backwards compatibility, the extra padding would automatically have > the same color as the background until it's explicitly set via the new API > call for the first time in the widget's lifetime. From that point they live > separate lives. This could be cleaned up the next time we break the API/ABI. I'm not sure we need explicit API for that. As I see it, this extra padding is part of the chrome not the content, so its colour should be determined via the usual style system (CSS), possibly with a special value ('unset'?) to say to use the same as terminal's bg colour. > - If colors are taken from the system theme, I think it should be the main > color of the Gtk+ theme (according to the dark/light switch). If we use a style colour for this, the theme has full control over it anyway. > - If colors are not taken from the system theme... then what? Do we want > another (hard-to-explain) element on the profile prefs' Colors tab? Or just > some magic and some underlying dconf variable? I'd say to still use the theme for this since it's chrome. > - When fullscreened, g-t could automatically set it to pitch black instead, > and restore when unfullscreened. Is this a good idea? AFAIK themes can style chrome differently for fullscreened windows (there's a style class for that, I think), so this is covered by making it a style property.
> I'm not sure we need explicit API for that. As I see it, this extra padding > is part of the chrome not the content, so its colour should be determined > via the usual style system (CSS), possibly with a special value ('unset'?) > to say to use the same as terminal's bg colour. Sounds good to me.
Another question: should we distribute the extra space equally around all sides half on left/top, half on right/bottom, or continue to put it all at right/bottom ?
Vertically: I'd keep the poisitioning as-is, see bug 746690 comment 10. This is how we get the most out of the available space with smooth scrolling, without IMO introducing misleading behavior. But let's wait for a few months for users' feedback on smooth scrolling. Horizontally: I'd also keep the contents left-aligned, I'm generally not a big fan of centered layouts, and the contents inside the terminal is typically left-aligned too, so extra space on the right is IMO less distracting. For both, another argument is lazyness / code simplicity. I wouldn't like to introduce and maintain the necessary (and easy to break) boilerplate all throughout the codebase to offset by this extra amount. Even the simple 1px padding used to be computed incorrectly at many places.
Well, I was concerned that if the extra padding will be in a different colour, putting the space all on one side will make the widget look disturbingly asymmetrical... I guess we could just use the (gtk) background colour, ie gtk_render_background(). That might interfere with transparency though...
Given that this extra amount is usually very small, "evenly" distributing an odd number of pixels (e.g. 1px on the left, 2px on the right) probably isn't any better. I'm not sure on this, I just don't feel like adding the necessary code complexity to try this out :)
Also, think about slowly resizing a vte-based app that doesn't have geometry hints. How silly would it look like with the centered content e.g. moving to the right and suddenly jumping back to the left, etc. YMMV.
Created attachment 323204 [details] [review] poc patch Having tried this, I don't think it can work. See what happens when there's more than a screenful of output, and you scroll back. (Use a maximised window, Ctrl+KeypadPlus to increase font size, if necessary, to create an extra space that'smore than just 1 or 2 pixels.)
I'm sure it can work, this PoC is just not there yet :) The required implementation might be much more complex, dunno. What I had in mind is to have the vertical extra gap vanish as you begin to scroll back. (Roughly as if it belonged to the actual contents that's being scrolled, although the standard padding makes it more complicated than this.) Another option is never to draw anything in the bottom extra padding (as we did before smooth scrolling was introduced).
In Terminix the entire widget's background became pink :-D
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/2292.