1. 2

  2. 3

    I wish it didn’t need to take them a decade of CSS dark ages to realise why GTK+ 2 theme colors were necessary.

    1. 2

      GTK allows different sources to provide styling, and each style provider is given a priority: GTK offers the fallback, theme, settings, application, and user priorities, from the lowest to the highest. If we follow these priorities and GTK loads the colors from the settings with the settings priority, it means we offer what I consider the perfect priority order, from the lowest to the highest:

      • theme provided colors (theme priority);
      • vendor provided colors (settings priority);
      • user provided colors (settings priority, overriding the vendor’s default);
      • application provided colors (application priority).

      So, the previous GTK theme infrastructure put user priorities above everything else, but the new scheme puts application priorities above everything else. That’s certainly a valid trade-off, and seems (to me) to be consistent with GNOME cultural values, but for some reason it grates against my values even if I don’t have a concrete alternative.

      1. 2

        I think this is more or less an artifact of what they want to enable support for, and honestly I think it’s the right trade-off. This priority mechanism seems to be meant to enable applications to do things like customize the headerbar background depending on the application’s mode (e.g. private mode for browsers). There’s some potential for abuse here but then again, there’s always potential for abuse, in anything.

        Application developers can inject CSS into their application’s theme today (edit: or, at least, they could back when I last touched GTK code about 4 years ago?), but it’s a fragile mechanism that tends to break often (maybe because of the approach that Gnome took for these things but that’s besides the point by now, you don’t revert ten years of that overnight). This, at least, offers a standard mechanism (standard as in Adwaita will implement it – other themes would have to follow).

      2. 2

        It’s a little unsettling that the list of reasons reads more like a condescending “yeah, I guess” than a usability improvement, and doesn’t list the primary reason why color schemes were (and still are) used in many user interfaces: the default colour scheme doesn’t look the same on all monitors, and isn’t appropriate for all users. I mean yes, the technology we have today is not the same one that we had back in 1992 and the constraints and limits are not literally the same as in the age of the M6845, but we still have to solve similar problems.

        I don’t want to change the Adwaita colour scheme “to make the system more my own”, I want to change it because my laptop’s screen renders a retina-burning blue that makes my only valid eye sore after three hours, and I have to stare at it for at least five more after that.

        Up until 3.18 or so when I finally gave up, I’ve had to resort to hacking up Adwaita (at pretty much every release, of course!). Not to satisfy some inner urge to mess up with designers’ work but because I couldn’t use the designers’ work. Through no fault of their own, I get it, Adwaita isn’t designed for one-eyed users of poor-quality monitors but it’s not like I was going to buy a new laptop just so that I could use XFCE or Gnome!

        Unfortunately, this proposal seems to be aimed more at application (!?) developers than platform integrators – in fact, for some reason, the author says that:

        While I don’t think this should be supported and implemented, and I think this API should only be between the GTK team and application developers, I’ll explain how I think we can extend it to let the vendors and the users set the colors.

        The mechanism that the author describes is actually pretty cool and clean, but given how the Gnome project has treated theming and theme developers in the past, I don’t expect this is going to end well…