Can you start Ardour from a terminal? there should be messages to stderr:
Color <colorname> not found
.
it would be interesting to see which specific color is missing from the color theme you use.
Can you start Ardour from a terminal? there should be messages to stderr:
Color <colorname> not found
.
it would be interesting to see which specific color is missing from the color theme you use.
I get lots of these
Color generic button: outline not found
Color fader outline not found
Color meter outline not found
Do you have custom theme in your preferences folder? Assuming GNU/Linux
ls ~/.config/ardour8/*.colors
/home/dave/.config/ardour8/my-dark-ardour-8.6.colors
/home/dave/.config/ardour8/my-dark-ardour.colors
/home/dave/.config/ardour8/my-xcolors-ardour-8.6.colors
/home/dave/.config/ardour8/my-xcolors-ardour.colors
So it seem those customized color files do not have the “outline” colors.
Does removing those color files help?
Before removing the files, can you upload my-dark-ardour.colors
. I am interested in any differences to the file that comes with Ardour: ardour/gtk2_ardour/themes/dark-ardour.colors at master · Ardour/ardour · GitHub
Yes, removing those files gets rid of the funky colours.
https://filedn.eu/larUQgXOwVjQdvpPaD96lHH/my-dark-ardour.colors
well, I’m using a customized “xcolours” theme, too, and I also have those funny colourful frames around buttons in 8.7… what irritates me: I’m sure, I never ever even tried to introduce any colours from outside Ardour’s colourpool.
That means, when I am confronted now with a “incompatible colours” issue, the colourpool itself must have been changed.
What leads me to the question: why?
Surely this isn’t working properly? IIUC my-dark-[whatever].colors is a complete colour list whereas (surely?) it’d work better if it only contained “my” colours?? In other words, if I’ve only changed 8 colours it’ll only contain 8 entries. Each Ardour release could then load whichever .colors list is appropriate for itself - and it could then update those by changing any entries it finds in my-dark.colors.
This has been an ogoing issue since day 1 but surely that’d fix it??
I believe a fix was pushed recently - Require user's color theme files to be versioned · Ardour/ardour@66fdee2 · GitHub
@DHealey, I might be misreading it but to me, that link implies that a newer version of Ardour won’t now try to load an older version of the user’s personalised .color file - thereby avoiding the random colour problem. But (presumably?) that’ll also mean that the user’s preferences won’t get transferred from an old installation into a newer version. Or have I misunderstood it??
It has always been our intent to not load personalized color files in newer versions, for reasons illustrated by this bug.
Outline colors for generic buttons were added sometime during the 8.x development cycle; personalized color files that predated this are missing those colors, with this result.
The fix done a day or two ago prevents these files from being used.
We have never seen a coherent way to merge new color files in a release with existing color files from the user, but we could be missing something.
What about doing it like CSS? You load the base colour theme, then load the user’s customisations on top of that. This way it doesn’t matter if the user has missing colours because they are present in the underlying colour scheme. If it’s a totally custom colour scheme then there won’t be a base one so give them the funky colours (or perhaps a single default colour) so they understand there are new colour options available which they don’t have.
I think the emphasis is on coherent.
If you mix new original colors with user modified user colors, you can also get some funny looking theme.
Well how inverting my idea, use the user’s by default and then any that are missing you apply from the base theme? Either of these methods has to be better than leaving it to the user to do this merge manually.
again my question: why do you feel the necessity to change the colourpattern? Does it sound better? Or are the previously existing (huge number of) colours no longer sufficient?
I ask, because trying to regain at least part of my visual setup (which is friendly to my eyes) after each major versionchange is not an easy but timeconsuming exersize.
Get me right: I will not complain, I’m using a fantastic DAW for less money incl. access to a great community, I only would like to understand, why I frequently need to do this exersize.
That seems sensible to me… initially load the user’s theme and if its file version is either lower than Ardour’s current version (or if the user’s theme is unversioned) load Ardour’s theme file and then extract any new entries which don’t exist in the user’s file. Then save the user’s file with the updated version number.
That’d work surely?
[Edit…] No, actually that wouldn’t work because if the devs deliberately change some colours, the new values would get lost. It really needs to be done the way I suggested - whereby the user’s file contains only entries that the user re-defined. And therefore the user’s file needn’t be versioned.
It may or may not [1] result in “no missing colors”, but as mentioned before we intentionally did avoid doing that.
–
PS. Mixbus already behaved as we intended Ardour to, and every minor version required users to update their custom colors.
PPS. there is also the problem that if a color is removed from the main theme, it should also be dropped from the user’s custom file.
[1] when working on a new color theme you do want missing colors to show up prominently.
Sorry Robin, I edited my post just as you were replying.
I don’t understand the difficulty, it’s standard behaviour when a system has user customisable settings - not just colour themes.
Apply the base setting, then apply user changes. Anything the user settings is missing is handled by the base, anything in the user settings that is no longer used (deprecated) is ignored. No need to overwrite the user’s file, you just merge them dynamically at run time.
If a colour is dropped from the main thing it doesn’t matter if it’s still present in the user’s file, but if you want you could put a comment (I don’t know if colour themes support comments) to mark it as deprecated.
The problem is that there is no fixed list of colors anywhere. I deliberately designed the color system to work this way (might have been a mistake, might not).
We load a set of colors and alias and color-modifier definitions; later we look up colors and aliases and color-modifiers. At no time do we know all the colors we’re going to need, and at no time do we know all the colors we expect.
Thus, we have no concept of “missing” at the time of loading. When we later fail to find a color, we have no differentiaton between “loaded from file X” or “loaded from file Y”.
This could all change, but the system wasn’t designed to be cascading the way that CSS is.