Kodi Community Forum

I'm never sure where the best place to post such things are, as they border on feature requests, bug reports and just plain asking for advice on better ways to accomplish what I want. So, if this would be better elsewhere, please do move it

I'm a great fan of user customisation, and have been playing about with user customisation of text colors using a variable - something like


With all references to the selected color then being (for example)


and the color being chosen via a custom window in the skin. Generally this works great, except in two instances (that I've noticed in the ≈12 hours since I implemented this) - label2's on Buttons which display such a label don't use the color (for example, the currently selected skin on the Select Skin button in Settings > Appearance), and the label on Edit controls.

In these cases, the label doesn't appear, suggesting it isn't getting any color value at all. All other instances (that I've tested so far) correctly use the color specified by the variable.

To be clear, I'm developing against the latest Helix nightlies, but have confirmed the same behaviour in the latest Gotham release. Is this a known issue? If so, is there any chance of a fix in Helix? If either of the previous are true, is there any more information I can provide? And if neither are true, can anyone suggest any alternative methods for allowing the user to set the color of text that would apply to label2's and edit controls?

Thanks

For the ones that don't seem to take a VAR you could probably set a fallback for now.

<textcolor fallback="color">

Not a fix but at least they would not be empty.

you could use for all your labels you want to color and let label2, edits etc fallback to <textcolor>
still a workaround though.

(2014-08-31, 02:11)MassIV Wrote: [ -> ]For the ones that don't seem to take a VAR you could probably set a fallback for now.

<textcolor fallback="color">

Not a fix but at least they would not be empty.

That simplifies my variables (no more <value/> node) - and thank you for that - but as soon as the user sets a color (so the variable is actually returning something), the label2's and edit control still appear invisible. It's an improvement, though (it works until the user starts to customise - that's a infinite improvement over the current state )

(2014-08-31, 02:13)phil65 Wrote: [ -> ]you could use

Code:

<label>[COLOR $VAR[FontColorVar]] SomeText [/COLOR]</label>

for all your labels you want to color and let label2, edits etc fallback to <textcolor>
still a workaround though.

TBH, that feels like I'm working around something that already works (the primary labels) rather than the issue. If it was just about providing a fallback for that label2's etc I'd be providing all the colors via themes but, with over 200 possible background and overlay colors (I really should have checked this actually worked before writing the color selection dialog ), I can't program that many themes and using fallbacks for the label2's etc limits it even more. Thanks for the suggestion, though

no, it works around havin disappearing label2´s etc when coloring the primary font with <textcolor>. that way you can choose both colors independently. (does not work for for buttons generated by xbmc itself though, those with default ids because you cant edit the <label> tag there)

...and you can also use of course

(2014-08-31, 02:28)phil65 Wrote: [ -> ]no, it works around havin disappearing label2´s etc when coloring the primary font with <textcolor>. that way you can choose both colors independently. (does not work for for buttons generated by xbmc itself though, those with default ids because you cant edit the <label> tag there)

You're right of course (at my age it takes time to actually think through these things, let alone test them!) With your suggestion, the user choice is used for the primary label, the label2 (or the edit control) goes to the color selected in the color theme (not the fallback, which isn't specified with this method - which is where I'm going to claim my confusion came from ). A quick test suggests this works quite nicely as a workaround until such time as (hopefully) a fix comes into Kodi. Thank you

phil65's solution works great - except for one huge issue By specifying the color within the <label/> tag, the ability to vary the label color depending on focus (or disabled, or even invalid) is lost, which severely limits the usability of the controls.. So close - very VERY close - yet so far

You can vary the color with the control.hasfocus(id) condition in your variable.

Ingenious Feels like I'm getting close to sorting this (with everyones wonderful help). That's got it working everywhere where I define the instances of the controls. Any idea how it could be extended to SettingsCategory.xml for example, where I just provide a default button, and so can't add [COLOR] tags into the label? Thanks again.

(2014-08-31, 22:59)`Black Wrote: [ -> ]You can vary the color with the control.hasfocus(id) condition in your variable.

Would be even simpler if we could use Control.HasFocus() without the id and XBMC used the current control's ID as fallback.

I just discovered this thread after running into this same issue too.

I have been playing around to make all colors in my skin user configurable by setting a Skin String as color on all controls.
This works very well for every part of the skin, except:

- label2 of a button control
- label2 of a slider control
- text of a textbox control while inside a container

Any chance this will be fixed some day ?

Also doesn't work for edit controls.

(2015-05-19, 17:35)braz Wrote: [ -> ]Also doesn't work for edit controls.

Confirmed, doesn't work either...

For now I'll just use the static color for the elements that don't like the dynamic color set by a VAR or Skin setting.

Is this to be considered a bug in kodi or is it by design and shouldn't we be using the VAR's on color parameter at all ?

I use VARs for heaps of colour stuff, so I hope its not by design...

Maybe using the new include type (Isengard) ?


and call it :


Didn't tried it so far but this should avoid the $VAR use.