The problem is that the approach regarding color-schemes in columns ui is one of its most inconsistent behaviours. It is basically trying to pack two conflicting design-approaches under one hood.

Approach 1: Be a "simple UI" (ahem, anyone look at the complexity of its prefs?) where the user simply adds columns with the mouse, types in the tagfield to display, and then set the colors via the colors & font page with the mouse. This approach comes from the most early days of columns ui where it was indeed a rather simple UI (compared to how the prefs and features are like today)

Approach 2: Be a "poweruser UI" which allows formatting-string authors to beat the crap out of TAGZ and add all kinds of poweruser-features. Those would then create advanced FCSs with configuration-settings in the globals - less skilled users could then just import them, and configure them via the settings in the global-vars.

The Problem: Both conflict with each other regarding colors. Thats why string-colors do override color-picker colors. But even in that regard the behaviour is inconsistent: You can set stuff with the color pickers which you cannot set via strings. At the same time, you can set stuff with strings which you cannot set via color-pickers. Thus, neither strings nor color-pickers have full control - as soon you want control over ALL colors, the user needs to switch back-and-forth between the two approachs - with the result that the whole thing becomes more difficult and complex to use, than "Approach 2".

When considering the described main motivation behind availability of global-vars to other plugins, then the usability-factor becomes even more worse - imagine this: You've got an FCS which consists of playlist-layout code, trackinfo-panel code, and osd-code. It has a central configuration section in the columns UI global-vars where you can set the colors - to make the point even more obvious, lets asume the user selects a color-scheme there. So far so good, but there are some colors to which the strings have no access, so the user has to set them seperately via color-pickers. Then, the trackinfo-panel may as well have some colors which can only be set via color-pickers(i dunno, i didn't use it yet, its just a guess), so the user has to manually set the colors there as well. Next, the same has to be done for the OSD-colors.

A manual for the above hypothetic FCS will then read like this: "You can simply set the colorscheme in the configuration-section of the globals. BUT, whenever you change the colorscheme, you also need to manually adjust some colors in the columns ui colors & fonts tab, next you manually need to do that in the trackinfo-panel settings, and last you need to do it in the OSD. You need to repeat all those steps whenever you change the color-scheme in the configuration-section". Great, if the user has to do so much work manually, then you can as well axe colorschemes completely and let the user set every color manually in hundreds of component-prefs(exaggeration).

This is why the current approach is a mess. Either have color-pickers only, or have string-defined colors only, but not both. Since the majority of users want powerful playlist-styles (the string-approach), the color-pickers should be axed imho. But well, thats just my opinion.

I partially agree with Lyx. Even though I'm not really affected by this myself, since I prefer to have default system colors anyway (optionally with row background color tinted based on album tag), I see that there is an inconsistency between visual and textual color configuration. However, I think Lyx' approach goes into the wrong direction, because it increases the burden of the titleformatting code, whose complexity is one of the biggest weaknesses of Columns UI. (Perhaps the code wouldn't really be more complex, but there would be no more alternative!)

I would propose the following instead: Have a visual configuration for user defined colors, and manage color schemes in the UI as well. Let styling scripts override colors, so you can perform blending and what-have-you, but the user would be able to set the base colors in the visual editor without having to face the rather unfriendly looking formatting code.

If you ever wondered what the "Appearance" page is that foo_common adds, that is an as of yet unfinished implementation of an editor that allows the user to edit color settings for multiple components in one place. As an additional feature, it allows color variables to be track the value of another variable, so for example <insert name of panel> would always use the same background color as the playlist, unless the user overrides this on a per-variable basis. Also, the "root" variables are set to track the system settings by default.

The problem is that those colors would either need to be standardized (and i'm not just talking about bg, fg, borders, etc.... more something like "bg-color", "alternative bg-color", "fg color", "alternative fg color", "specials fg color", etc.)....... or the vars and colors which the user can set in those dialogs would need to be *customizable* - that is, a colors can be added and removed...... with import-export support of course.

Personally, even if the above would be implemented, it still imho would not yet be the optimal approach. Something similiar to what imho would be the optimal approach was proposed in the discussion about a year ago:

Have a tab with the following layout:
1: var-name, var-value, "set"-button
2: var-name, var-value, "set"-button
3: var-name, var-value, "set"-button
...


The set-button would open a popup which could either be a text-field to enter something, or a color-picker which would automatically set the var-value to $rgb(r,g,b).

This tab should act as central configuration-place for vars. The vars would automatically be exported, and be available to formatting-strings. Thus replacing "configuration-sections" in formatting-strings. It should also be possible to add vars to the above window(easy to setup, just choose varname and if its a color or a normal value). Such a tab should someway be standardized regarding the UI, so that it looks the same for any component which implements it.

What i am not sure about is how to solve the following:
Component1, has above var-page
Component2, as well has above var page

Now the vars in component1 define some kind of color-scheme......... how to make those colors override certain vars in component2? Maybe when setting a var, allow to tell it that it should use another already existing global-var.

Like:
Component1: var1=x
Component2: var2=var1

But i'm not sure how to implement such "symbolic links" UI-wise. And of course theres the danger of circular-references!

- Lyx

Well, that's exactly what I meant with "user defined colors".

foo_common aims for a different goal: Instead of having each component (re-)implement an editor, provide one global editor. Regarding variable names, I think just a name is not enough. There should be a variable name that is used in formatting scripts, and a user-friendly name. Add a description if you like.

Circular references are rather easy to check for. However, before foo_common, I had a different, more complex design in mind. However, while I implemented that it became apparent that the system would get too complicated for all involved parties: me as programmer of the framework (including the editor), the programmers of components that would use this system, and last but not least the user. So for now, foo_common aims for a simpler system, that purposefully omits to specify several things, for example it does not specify how to access colors in formatting scripts.
It only deals with typed configuration objects. The type can be arbitrary, also the visual editor only deals with the built-in types: colors, fonts, and formatting strings. It also defines several global objects for each type, and allows to transparently integrate system settings into this scheme. For example, components will be able to access any system color available through the GetSysColor() API as a "color object". It also provides change notifications and the aforementioned tracking mechanism, as well as a visual editor and (planned) a configuration import/export facility.

I know that this may not be the perfect solution for you, but personally, I would rather have a limited solution eventually than wait forever for a perfect one (assuming it even exists).

I'm sorry - from the first description of it, it seemed as if it would only be for managing colors(from your previous post, it seems thats not the case). I didn't know that you intended it to act as a central place for global cross-component settings(i.e. also user-defined vars(not colors). And it currently doesn't allow the user to add/remove custom objects(but i now asume thats because its still in an early stage of development?).


Hmm, i'm not sure if i understand the implication of this. Do you mean that this could lead to the same common-color being accessed in varying ways in component formatting-strings?

The rest of your description sounds very promising.

- Lyx

I am not sure how to handle that yet. To be honest, I already changed my mind several times regarding how to handle user-defined objects. The current implementation does not support for them, though since objects are dynamic in lifetime, a component could add them and they would be accessible through the editor. You currently couldn't add or remove them through the global editor, which would be a major disadvantage.

You should know that I designed the current system without thinking of manipulating colors in scripts. Furthermore, a given variable name in script code would not always resolve to the same color object. I'll try to explain this using a hypothetical version of the Columns UI playlist that is adapted for this system. There are some global color objects for background, text, and so on. Since foobar2000 is a playlist-centric application, they are in a folder (this is purely a user-interface feature!) called "Playlist". Now the Columns playlist implements its own color objects for these settings for each column which are set up to track the global values by default. (One could even imagine that it might add an intermediate layer, but that is irrelevant for this discussion.) Clearly, "bg-color" (or whatever the name would be) resolves to a different object for columns 1 and 2.

By the way, I intentionally left out editing tracking sources to reduce the complexity of the implementation (and the future user interface; it could get somewhat confusing), though I think this could be added later as an editor feature that is transparent to components.

Moderation: Posts here are split to prevent them from drowning in foo_ui_columns thread.

Post by musicmusic in original thread containing reply to part of Lyx' first post here

Maybe this feature would be worth a second look? It may make sense to not just use it as a visual cue, but instead more like a "path".

Example:
Navigator_FCS \ Configuration \ Some_setting_here

This would mainly be useful for import-export functionality (i.e. only exporting or importing a certain "folder" of the path... like i.e. "Navigator_FCS \ Configuration".

I'm not talking about seperate namespaces here - all vars in all "folders" could share the same namespace.

- Lyx