Unify GTK2 and GTK3 headerbar theming

Bug #1516309 reported by Adam Bieńkowski
6
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.get_style_context().remove_class("header-bar").
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
Revision history for this message
Danielle Foré (danrabbit) wrote :

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

Changed in egtk:
status: New → Opinion
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related blueprints

Remote bug watches

Bug watches keep track of this bug in other bug trackers.