Unify GTK2 and GTK3 headerbar theming
Bug #1516309 reported by
Adam Bieńkowski
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
elementary Stylesheet |
Opinion
|
Undecided
|
Unassigned |
Bug Description
As in current state (with GTK 3.18) we have 3 types of headerbar frames:
1. Apps that doesn't use them, they are drawn by GTK.
2. Apps that use headerbar.
3. Apps that use headerbar natively.
Since GTK 3.16 we can theme all GTK titlebars, I think we should somehow merge the look of first and second situation.
Feel free to mark this as opinion or invalid though...
description: | updated |
To post a comment you must log in.
Okay so there is a plan, but also a problem here:
Overall, the idea is that this differentiation is a good thing. We don't want all window decorations to appear exactly the same. But we also have a problem we have to consider:
We have the most common case which is apps like Scratch or Files or Music or anything else where we use headerbar normally and we have highly actionable items. Essentially this is combining the toolbar and titlebar from the old days.
We have apps like Terminal or CapNet that have custom items in the titlebar or apps like Audience in which the titlebar is clearly distinguished from the content, but that don't contain important highly actionable items like toolitems or pathbars or the like. For this kinds of apps, it makes sense to have headerbar. get_style_ context( ).remove_ class(" header- bar") because we want to have custom items there, but it's not so important that we need to be taking up the kind of screen real estate that the full headerbar consumes.
Then we have legacy app designs like Transmission, File Roller, Inkscape, Gimp etc. These apps place a menubar and toolbar right below the titlebar. This whole area of window chrome appears as a single continuous piece in the same way that headerbar appears as a single continuous piece. So changing .default-decoration to look the same as headerbar. get_style_ context( ).remove_ class(" header- bar") would actually break the visual design of these legacy apps.
But then there's another possibility for future apps and that is apps in which the titlebar is extremely unimportant. We don't need to place action items there and we don't need to separate the title area from the content. These are apps like Agenda and I'd like to facilitate a clean design for those kinds of apps. This is what I intend to use .default-decoration for when we don't have to worry about legacy apps anymore.
So, because of all of this, I think I'm gonna mark this one as "opinion".
TL;DR We gotta leave it for now for legacy apps and when we don't have to worry about legacy apps there's another plan altogether for .default-decoration