GNOME bug 121866 would like a way to set drawing colours according to palette entries in bitmap images in the same theme, as well as giving literal RGB values or giving a reference to a GTK colour. It is suggested by the reporter that this could be done with the XPM format, which allows colours– or rather, entries in the palette– to be named instead of specified: foreground, for example.
This is quite a vague requirement. Because this requires a change to the theme format, it must be committed first on a branch. However, using bitmaps in themes at all is somewhat deprecated.
A useful variation on this idea would be to allow a set of colours to be undefined within a theme, which could be done by extending v2’s support for colour constants, and then allowing other sub-themes to specify only the missing colours. Or perhaps the user could choose the colours for themselves as parameters to the theme; this part we could even do already with no change to the theme format, by adding a new GConf key which allowed redefinition of colour constants in the current theme. You can imagine a standard utility which would read the theme file and give the user colour pickers for each constant, then set the values in GConf.
This would then bring us back to the original problem and might require us to be able to change a specific colour in bitmaps as appropriate; alternatively, we could just say it was one more reason why bitmaps in themes are a bad idea.
Photo © Bernat Casero, cc-by-nc-nd.
It’s not really obvious exactly what the original bug filer wanted his Metacity themes to match. Matching various colours in the active GTK+ theme is pretty easy, although I don’t believe you can access GTK+ symbolic colours which might possibly be useful (I believe this is how the colour-pickers in Ubuntu’s GTK theme editor work).
Alternatively, if the idea is to have multiple themes with the same base design and different accent colours, I think a better approach would be to add separate sub-theme files that allow colour-constants to be overridden. You could add a ‘subtheme’ gconf key in parallel to the existing ‘theme’ key, and older themes with no sub-themes would just ignore it. Likewise, older Metacity versions would ignore the sub-theme files in newer themes so compatibility would be preserved.
Another possibility is that this bug can be marked FIXED by the addition of colour constants to the V2 theme format – or even by the “colorize” attribute on the image draw_op.