Ardour's themes color definitions change proposal

Right now in Ardour there is already a “fixed list of colors” (albeit not “officially” defined) in the <Colors> definitions section, this is also shown in the Settings > Colors > Palette tab:

The biggest issue I encountered when making the Xcolors theme was the fact that these “fixed” colors where assigned to “names”, and then these “names” were used in the <ColorAliases> section, to alias other UI elements colors from the “names” defined in the <Colors> section.

To explain what my proposal is about:

Let’s say you spot a color in the UI you want to change, for example: “crossfade editor point outline”.
You go look in the theme source and find: <ColorAlias name="crossfade editor point outline" alias="alert:blue"/>

Then you have to go look into the <Colors> definitions and look up what color “alert:blue” is.

Now, multiply this for almost every UI element’s color in a theme, this is going to take a “bit” of time for each one.

In short, with the current system you have to look at what <ColorAlias> name is referencing to for every element you want to check or change. If you want to change color for the element Z, you have to look first of which alias is element Z, once you discover it’s element Y then you have to look at what color X the element Y is assigned.

My proposal is instead moving the current <Colors>names” (like “alert:blue”) in the <ColorAlias> definitions section, and use something like “color4” or “blue” in the <Colors> section (or whatever it would make sense to define a palette, be it fixed or left to the choice of the theme’s maker, I have no strong opinion on this yet). In this way we would have a 1 to 1 relationship on what we see in the UI and what’s in the theme source: element Z is of color X, or like in the example above “crossfade editor point outline” will be “color4”.

Another advantage would be the ability to change colors in bulk. Let’s say I want to change all the “blue” (used for the “fader” in the mixer strip and “knobs” fills, etc.) to “green”.
All I have to do is changing one or two color (let’s say color4 and color 12, our “blue” colors) defined in the “<Colors>” section, without having to remember if it was “widget:blue” or “blue:darker” (or even if they are actually blue :crazy_face:), or in another way just substitute every occurrence of color4 and color12 with color2 and color10 (our “green” colors).

I’ m not sure this change would even require big code changes, it’s almost the same as it is working now, with the only difference being the current “names” in the <Colors> section going into the <ColorAlias> section.

I also think it could end in a better and easier way for user to customize themes to their liking, being it exposed in the Palette tab or simply editing the theme source.

I wanted to open an feature request about this in the tracker, however I thought is better to have feedback from the devs/community first.

Another idea that could be implemented is to make the user’s “customized” themes to inherit the original theme colors, and save in the “customized” theme only the colors the user had changed. In this way we could mitigate the issues highlighted here: Color theme issues with Ardour 8.7

I did something similar when creating the arc theme for ardour (ardour-arc-theme/arc-ardour.colors at master · jean-emmanuel/ardour-arc-theme · GitHub), I did the renaming once and now it’s indeed very convenient and easy to maintain or to derivate from. There’s however a small drawback as ardour seems to have trouble switching to/from this theme properly (I guess due to how aliases are handled), anyway, works for me.

1 Like

I know you project, very well done! :slight_smile:
I had the same idea before (I had a protoype I didn’t share) but the problems you are encountering (switching theme is broken if you don’t use Ardour’s “names” structure) made me abandon the idea. That’s exactly the problem I want to avoid, having colors separated from names would make theming, also in a “automated” way, much easier, among other possible pros.