Theme parsing (+some)

Specifically, literally theme-parser.c in marco/src/ui/

After spending a few hours fixing pieces of copypasta errors in the "Traditional" themes, one thing that really stands out to me is just how much of this maintenance headache could be wiped out entirely if the theme parser just supported color variables. To give a very cut-down example of what I mean:

<draw_ops name="button_bg">
	<line color="shade/gtk:bg[SELECTED]/1.00" x1="2" y1="0" x2="width-3" y2="0"/>
<draw_ops name="button_bg_unfocused">
	<line color="shade/gtk:bg[NORMAL]/0.93" x1="2" y1="0" x2="width-3" y2="0"/>
<draw_ops name="button_bg_pressed">
	<line color="shade/gtk:bg[SELECTED]/1.0" x1="2" y1="height-2" x2="width-3" y2="height-2"/>
<draw_ops name="button_bg_unfocused_pressed">
	<line color="shade/gtk:bg[NORMAL]/1.05" x1="2" y1="height-2" x2="width-3" y2="height-2"/>

and so on. There's literally 30 to 50 lines of XML for each of those cases, with all of them using arbitrary shading constants, and the massive copypasting inevitably leading to lost synchronisation of all the pieces (gradients, etc) as time goes by and one fragment gets tweaked without the changes being replicated to all the other states.

It would be really easy to remove ALL of that duplication if the parser was extended to simply allow colors to be defined and passed to drawops. Since marco actually contains the theme parser, is it reasonable to consider it already forked? And if so, would you like me to patch it to add that functionality?

The result would look something like:

<draw_ops name="button_bg">
	<include name="button_bg_core"/>
<draw_ops name="button_bg_unfocused">
	<include name="button_bg_core"/>
<draw_ops name="button_bg_core">
	<line color="shade/gtk:paper/1.05" x1="2" y1="height-2" x2="width-3" y2="height-2"/>
etc etc etc

with all the ops modulating a base color (a pair of colors actually) in a consistent way with a single instance of the actual drawops calls.

The upside is, literally hundreds of lines of XML, per theme, would simply vanish. Without the copypasta, any modification to the style of "Button X" would automatically propagate to "Button X Unfocused" etc. As a new feature it would be completely backwards-compatible with existing themes.

The downside is, obviously, the theme parser would be distinctly forked. So when GNOME inevitably moves on to "metacity-4" themes or whatever, there'd need to be an actual merge rather than being able to simply take their code as is.

I'm willing to - more precisely, I'm offering to - do the work to add this capability. I think it would be a trivial amount of code, and I think it would make themes much easier to maintain.
The question is, does anyone want this capability? Is there actually enough time being spent on themes for it to be worth the negatives I've mentioned and any that I've missed?

So when GNOME inevitably moves on to "metacity-4" themes or whatever

GNOME dropped support for metacity themes years ago. There's the metacity window manager, used in GNOME Flashback, and then there's the Cinnamon window manager (muffin? I don't remember). Those are the only two, apart from Marco, that use the metacity theme spec, AFAIK.

Honestly at this point, I'd say to go ahead and implement whatever feature would bring back colors, and we'll worry about versioning after. I'm not opposed to creating our own marco-theme-1 spec with a fallback to metacity-theme-3. It's probably about time, and I can deal with the battle that will undoubtedly ensue upstream.

My main concern is with users being able to change colors easily. Right now all it takes is some CSS variables, and there are easy GUIs for parts of that. Can we have a theme spec that allows for something even easier than that? Maybe using gsettings to store theme colors?


Sadly, THIS one isn't actually about getting user choice back: it's simply to (hopefully) reduce the burdens of theme maintenance, and ensure that themes don't "rot" over time.
The colors here are so that the chunks of xml can use a dynamic "base" color for an element so that the actual DRAW calls can be reused regardless of the element's state, but it doesn't benefit useres directly.

Color is absolutely part of the "plan" before 20.04 comes out though. :slight_smile:
The thing is, a lot of the themes are in a state where actually fixing them to allow colors BACK is a burden itself, hence this assistance on that front first.

Zenity + a tiny script will handle the user-facing parts of theme repair, as you say - but again, only if the themes are in a fit state to support colors, which several? many? most? no longer are.

gsettings is POSSIBLY an option, but will probably have a lot of issues, especially with Qt apps etc. I'll give it some thought and do some research, but - and I want to make it clear that I'm not exaggerating this for comic effect - there are already FOUR other places where theme colors are set, and god only knows which one some random app is going to use - if any at all! :frowning:

(FYI, on 16.04 we have

org.mate.interface gtk-color-scheme 'fg_color:#000000000000\nbg_color:#b0b0b0b0b0b0\ntext_color:#1a1a1a1a1a1a\nbase_color:#e0e0e0e0e0e0\nselected_fg_color:#ffffffffffff\nselected_bg_color:#404040404040\ntooltip_fg_color:#000000000000\ntooltip_bg_color:#f5f5f5f5b5b5'

in gsettings, and the key does EXIST in 19.10, but it's not populated, so it's obviously not being referenced by anything at all in the current stack.


Okay - I'm in the middle of hardware maintenance on my dev box, but I'm planning on tackling this this weekend once the machine's back up.

It will be MASSIVELY easier to limit this capability to just "ink and paper", i.e. two colors and predefined names, rather than going all out and allowing "true" dynamic color var support. There aren't any elements in my theme at least that use more than two for anything, and I doubt there are "really" any in any theme, though I can imagine a case where a third COULD be useful. My plan is go with this much simpler approach, so if anyone can make a strong case for more than two, now's the time to do it.