I’m using GNOME for 4 months and I like it very much. There is one annoying thing for me however — inconsitent size of window titlebars. I see in GNOME four types of titlebars (here, I am talking only about GTK3 based apps):
Default decoration rendered client-side by GTK3. It’s used only on Wayland* when app DOES NOT use custom titlebar. Looks exactly the same as #2 type**.
Default decoration rendered server-side by Mutter/Metacity. It’s used on Xorg when application DOES NOT use custom titlebar. Looks exactly the same as #1 type**.
Custom titlebar specified by application but application does not use its feature at all. Contains the same information as #1 and #2 but it’s bigger because: a) Adwaita specifies min-height, b) GTK preserves space for optional subtitle.
Custom titlebar specified by app AND actively used by that app: subtitle, custom buttons etc.
I am showing this problem on screenshot (top: #1, #2, bottom: #3, #4):
I don’t understand why this inconsistecy still exists in the whole GNOME desktop, which try to be consitent in each other aspect. I can guess two reasons:
when CSDs was introduced, Mutter’s/Metacity’s decorations (#2) were inconsitent with CSD decorations from GTK (#3, #4) and app authors tried to fix it on its own ( A small note on window decorations | Florian Müllner but this is history);
GNOME design prefers bigger titlebars than smaller.
In my honest opnion this problem should be fixed this way:
Custom titlebar should be used ONLY when it’s …used. Simple rule for apps authors: when you don’t need to use subtitle or custom widget in titlebar, don’t set headerbar and allow GTK to do its work properly.
If GNOME design prefers bigger titlebars, this should be set in Adwaita by setting min-height for .default-decoration both client-side and server-side. (This way will allow gtk.css hackers like me and theme authors to specify other CONSISTENT design.)
What do you think about it? I’m going to send merge requests for apps which I think need that fix (if I will be able to) but I don’t want to fight with you so first I’m asking.
Not quite. The smaller titlebars were introduced when we changed mutter’s SSD to match GTK, because the big headerbar style without any custom controls felt excessive. It’s a popular criticism that everything in GNOME is too big and that there’s too much whitespace, and in this particular case the critics would have had a point.
That is, having two different sizes is intentional, and it’s because for default decorations, GNOME design prefers smaller titlebars.
There is actually a good reason why apps may want to use headerbars for all their windows: In GNOME, client-side and server-side decorations match, but the two may be very different in other environments.
So in order to make it easy for applications to use headerbars consistently, GtkDialog has a use-header-bar property. What happens is that the headerbar that is created in that case doesn’t use the “default-decoration” style, so it looks different from the titlebar GTK or mutter add otherwise.
IMHO this is best addressed in GTK itself. I’ve proposed this MR, let’s see how it goes.
If GNOME prefers smaller titlebars for default decorations IMHO default decoration should be used instead custom decoration if app does not need to add custom content to it. I mean: if app does not add content to headerbar, it should not specify it at all (by GtkWindow’s set_titlebar() nor by GtkDialog’s use-header-bar). I dont say about dialogs only here.
Also, in desktops other than GNOME people prefer server-side decoration so moving from custom titlebar to default decoration has additional benefit for other desktop’s users on Xorg — they will have decoration from window manager not from GTK which IS inconsistent but preferred by users of other desktops. Of course I do not require from GNOME authors to support other desktops this way.
===
Also, I don’t agree with your merge request. Maybe I just don’t understand it. If programmer creates GtkDialog object with use-header-bar=1, it creates dialog window with custom, not default decoration. In my understanding default decoration is when programmer does not touch it at all, does not have access to it. In that GtkDialog example programmer have access to it. Your change may be confusing for theme authors for example. Please look here: https://gitlab.gnome.org/fmuellner/gtk/blob/default-decoration-dialogs/gtk/gtkwindow.c#L3859
Still IMHO non-used headerbars should be changed to default decoration and GNOME apps should simply ignore the fact that on other desktops decorations won’t be consistent.
I disagree. If an application has a main window with a custom titlebar and a preference window with a plain titlebar, then it is perfectly reasonable to prefer consistency within the application over partial consistency with other, unrelated windows.
This is a care where it’s impossible to avoid inconsistency, and while you may disagree with the choice, it’s up to app developers which consistency they value more for their app.
No, by “default-decoration” I mean: A client-side titlebar that GTK adds with the “default-decoration” style.
The MR only changes how some client-side decorations look if no custom widgets are added to it. It does not change whether or not client-side decorations are used. That is, there is no case where server-side decorations are replaced by client-side decorations because of the MR.
That code has nothing to do with the MR. I didn’t even touch that file.
I mentioned this file to prove that default decoration should not be accessible for programmer.
Right but instead of adding empty custom headerbars application authors should have some better way to say “I want to make all my windows CSD”. This way should work like GTK_CSD=1 environment variable — for all windows.
Please tell mi if I’m wrong. Your MR does this: if there is headerbar on GtkDialog it adds “default-decoration” if there is no additional widgets nor subtitle on it. Yes?
It yes it… does not work as good as (GTK_CSD=1 + avoiding using non-used custom headerbars). Basically GTK preserve space for subtitle even when there is not it. Bigger height of custom headerbar comes from two things: a) min-height for .titlebar:not(.default-decoration) b) from preserved space for subtitle from GTK. Your change reduces size from a) but not from b) because GTK treats this headerbar as custom not default.
I am not sure whether I am right. It’s time to compile your MR.
Ok, sorry for my ignorance. Now, your MR seems understandable for me.
In GNOME all decoration are consistent regardless of type (csd, ssd, default or not). GNOME apps are enforcing CSD using empty non-used custom headebars for better inner-consistency* in desktops other than GNOME.
So, GNOME apps sacrifice code quality and readability (by using empty custom headerbars) to make them better in desktops other than GNOME by doing things unneeded in GNOME because mutter plays good with SSD. I don’t think its worth it. IMHO it’s better to ignore consistency in desktops other than GNOME.
This is decision of GNOME apps authors and I honor it. For me, end user of GNOME, the most important part is to make somehow decorations smaller when it’s possible/needed. But from programmer perspective I would choose ignore other desktops appearance and keep code clean and simple, enjoying default decoration from mutter/gtk when its applicable.
* – I mean consistency in app, not between app and environment.
If programmer creates GtkDialog object with use-header-bar=1, it creates dialog window with custom, not default decoration. In my understanding default decoration is when programmer does not touch it at all, does not have access to it. In that GtkDialog example programmer have access to it. Your change may be confusing for theme authors for example. Please look here: