From someone with too much time on their hands: Currently working on a cheat sheet/reference guide for the various colours used in the Radiant/Ambiant-MATE themes, both in the standard icon sets and the CSS files; would this be of use to anyone once compiled, with a view to making it easier to automatically create variants on the themes? Or do such things exist elsewhere?
@Cerise Easier, yes please! One thing I haven't got round to doing is exactly that - but in script form.
In theory, a shell script could:
- Ask for a colour hex (or more, for gradients/variants)
- Make a copy of the Ambiant-MATE / Radiant-MATE themes
- Change all references (in CSS and SVG files) from the green hex to the user-specified hex value.
- This might expose inconsistencies if a few hex values didn't change if they were extremely similar (e.g.
#87a556and#839f53) in which you could create a pull request inubuntu-mate-artwork.
- This might expose inconsistencies if a few hex values didn't change if they were extremely similar (e.g.
Once it can be scripted, and it works reliably - we could potentially have a screen in Welcome, or build packages with different colours. 
Thanks for the link! Did a very proof-of-concept script test with recolouring the Radiant-MATE SVG icons already and it worked pretty well, though that was just running it on a readymade copy (really new to working with scripting). The CSS will take a bit longer, though I've made a start; the problematic issue has been working with the PNG assets, especially the ones that don't have a SVG counterpart available (that I can see?)
I guess there's these two areas for consideration:
- SVGs & PNGs from the theme (
/usr/share/themes) - SVGs from the icon set (
/usr/share/icons/)
Icons in particular have symbolic links, so only the source file that it points to needs changing once.
In the theme, there's normally both - a tool like Imagemagik can be used as a command line interface to take the SVG and export them as PNGs (specifying the the correct size)
- /gtk-3.0/assets/radio-selected-alt.png
- /gtk-3.0/assets/radio-selected-alt.svg
- /gtk-3.0/assets/[email protected]
For PNGs without SVGs, a last resort might be to re-colour them. 
GIMP has a "Colorize..." option... there might be something in Imagemagik too.
If someone is willing to rip it off, the Numix Project has an app called Numix Folders which colourizes a variety of things. Sure that can be expanded to a lot more than what the app touches right now, however it requires gksu which had been removed since Artful so you'd need to first submit a fix to make it use pkexec instead, and debug the hell out of it after that.
Whoever wants to do this (as I am ill-experienced and my crack at it was slightly discouraging for my tiny little brain) wouldn't just be providing a way for people to easily mod Ambiance, but also fix up Numix Folders for Eoan before it gets gold.
Also, I would further advise going against the established means of doing default colours and omit the use of specific images for that; there is no need to have any specific images for different colours if the app's only purpose is to recolour everything anyway, and custom handles dealing with that just fine. Everything else should just be presets for the custom routine. That would probably shrink the size of the Ambiance / Radiance app in half, as well Numix Folders.
Very happy to see other people looking into ways to restore color choice.
A couple of quick things. First, to potentially save you some wasted time:
diff --git a/gtk-3.0/settings.ini b/gtk-3.0/settings.ini
this is a ridiculous FOURTH place where theme colors are specified. however, this one is deprecated, so hopefully nothing is actually trying to reference them from here.
[Settings]
-gtk-color-scheme = "base_color:#ff00ff\nbg_color:#b0b0b0\nfg_color:#000000\nselected_bg_color:#404040\nselected_fg_color:#ffff00\ntooltip_bg_color:#f5f5b5\ntooltip_fg_color:#000000\ntext_color:#ffff00\nlink_color:#0000ee\nvisited_link_color:#551a8b"
Doubtless there will be some piece of software somewhere that's given up on chasing the constantly-moving targets of the CADT, but I haven't run across any yet. (Those were canary colors, and they haven't shown up in anything).
Second: if you run into the "PNGs without SVGs" case lah7 mentions (which unfortunately is the case for Clearlooks), you will be hugely better off just "doing it right" in the first place, rather than doing it GNOME-style. Compositing images is trivial. Recoloring something that is ALREADY composited though is also often awkward, and generally impossible to actually do well other than by hand, as some of the real information in the image can have already been permanently lost. For one small set of images, done one time, doing things badly is easy enough that it's less effort, but if you later decide that you want even just a slightly different shade, you end up doing the exact same amount of work again, resulting in more work overall.
So my advice is, DON'T recolor the images "as is" - instead, separate them into layers (i.e. "The colored part, and the other part"). As an example (using TraditionalOk) the square of a checkbox is the "base" image, and the blue tint on the "hover" versions of it is what should really be a separate image. Once your images ARE separated like that, recoloring things like the hover layer becomes so trivial that you can automate it, and generating the new composited image is also so trivial that it can be automated. At that point, the "slightly different shade" case basically becomes free, costing you just a few seconds extra rather than doubling the total amount of work, so overall you very quickly come out ahead.
(If you decide to create SVGs for such cases, you'll also get what's likely to be a superior end result, though probably not by enough to actually be visible unless you're on a 4K display and very close to it, so I wouldn't worry too much about that side of things).
Hopefully that made sense. If you need it explained better, I can try to write something up over the weekend. Good luck!
Makes sense in general, as does using editable presets over workable colours in a 'template' version of any files.
As a note, the SVGs in /gtk-3.0/assets are, at least in Disco, kind of a mess with regards to how the colours/gradients are defined - the files are something like 20 times as big as they could be thanks to a lot of redundant gradient etc definitions, even before optimising the structure of the image for recolouring... I'm not sure if this is part of the image-optimisation that's happening for Eoan's paper-cut tweaks?
As for the SVG-less images, those seem to mostly be cases where the image itself will be lengthened or scaled (eg. scale-horizontal-trough.png) and assets that work directly with them (sliders for the scales): I suspect this might be related to how GTK handles sizing such things?
Are there any official art team guidelines with regard to how the images were designed, etc?
Just another thought: Some parts of the CSS might use a RGB or RGBA value instead of a hex value. For example:
rgba(135, 165, 86, 1) = #87a556 (Alpha 100%)
Or
rgba(135, 165, 86) = #87a556
Also bearing in mind the whitespace might not be consistent.
Not that I know of for Ubuntu MATE or MATE Desktop themes. Ambiant-MATE is based on Ambiance for the theme and the Humanity for the icons, both of which were Ubuntu's / Canonical's.
I think I'm going to try cobbling up a script over the next few days. My objective is to simply re-colour the existing green.
gtk-widgets.css seems to be the biggest user of RGBA over hex colour values; I suspect that it might be connected to needing to specify how the transparency of said widgets is handled, or with the transparency of shadows? That's probably for someone more familiar with the actual system to determine, though...
Thanks for answering a question I hadn't managed to get around to asking, though; I'd been wondering if there was a source further back for the missing SVG assets, or whether there was any useful information to be gleaned with regard to reconstructing them.
Progress: I've managed to go through and find all the green variants in the SVG images; threw together a couple of quick search-replace scripts to test them out and pretty sure I've got them. Next hurdle is the CSS...
Working on cleaning things up so they're in a more usable format. It's obvious that some colours are incredibly similar, and yet they're not actual shared hex values across images - the above noted variants on #87A556 being an obvious case. Some icons use gradients with up to four colours just for one little feature, too! There are also cases where it's a problem that the colours are shared - applications-internet.svg uses the stock green shade for the landmasses on its globe.
As someone new to open source collaboration, where would be the best place to upload/share the material I have?
I've been working on a script - which I ended up writing in Python - and it's shaping up to work quite nicely:
It is incomplete, as it doesn't make changes to the PNGs that don't have an SVG - so button borders are still green, for example. As noted in the previous posts. 
we can either re-create (or find) the original SVGs that generated them, or try modifying the colours in the raster image.
Yep, I noticed this when I initially looked at the SVGs. Luckily they seem consistent across the board.. I think each one has been accounted for, and the script uses a function to lighten/darken the hex value. Those values in this program will probably need some further tweaking to accurately match the original shades... they might look a bit too flat.
I created a PPA to contain packages for this program (which I've called ubuntu-mate-themes). I'll look at generating packages for each colour and then I guess we're much closer to having it a reality!
sudo add-apt-repository ppa:lah7/ubuntu-mate-colours
sudo apt install ubuntu-mate-colours-generator
See the README for usage. I'll be looking at automating/building packages for a few colours, so one could install ubuntu-mate-colours-blue and have an up-to-date "blue" variant of the Ambiant-MATE/Radiant-MATE theme.
GitHub is a good place, you can contribute to this new ubuntu-mate-colours repository by requesting changes (pull request) using Git, or create "gists" containing snippets and text to share with others.
5 Likes
Thanks again. I know I've probably been stating the obvious a whole bunch, so I'm very grateful to everyone here, and thanks for the info on how GitHub works. This looks great, though!
1 Like
I ran into a lot (literally 100%, IIRC) of this in the XML as well, working from the TraditionalOK theme: every color in it was using an explicit value rather than a reference to gtk:bg[NORMAL] etc. Note that there are also a lot of colors DERIVED from the core colors that you also want to be doing with math rather than explicitly in there (e.g. a highlight edge should be a blend of BG and white, etc).
1 Like
I owe a thank you to @Cerise for sparking interest in this idea last week. ubuntu-mate-colours is now shaping up quite well, but still has areas for improvement.
If anyone would like to give it a test run:
sudo add-apt-repository ppa:lah7/ubuntu-mate-colours
sudo apt install ubuntu-mate-colours-all // or -aqua, -blue, -red, etc
See the README for colours or if you'd like to create your own:
Any issues, please report to the Issues page -- there's also the opportunity to help out with contributions since I'll be shifting my focus on some other projects for now ( 
)
Since we lacked SVGs as discussed previously, I did accomplish the colour change using imagemagick - which seems to have turned out alright
2 Likes
No, thank you for taking this ball and running with it! Been working on SVG recreations, but it's been slow work, so I'm glad that imagemagick's doing the job. Spotted a couple of things, but will get those on GitHub as needed.
2 Likes
This is great.
Thanks a lot !
$ sudo add-apt-repository ppa:ubuntu-mate-colours 1 ↵ Cannot add PPA: 'ppa:~ubuntu-mate-colours/ubuntu/ppa'. ERROR: '~ubuntu-mate-colours' user or team does not exist. $
How stupid am I?
PS: Running latest full patch
DLS, please try
sudo add-apt-repository ppa:lah7/ubuntu-mate-colours
instead. I'll correct the original post above.
1 Like
Thanks