Foreground color of disabled RadioButtons and CheckBoxes

[imrohl]

Version of Radiance (latest release is 7.0-SNAPSHOT)

6.5

Sub-project (Common, Animation, Theming, Component, ...)

?

Version of Java (current minimum is 9)

17

Version of OS

Win 10

The issue you're experiencing (expected vs actual, screenshot, stack trace etc)

Normally RadioButtons and CheckBoxes have different foreground color depending on their state (enabled=black, disabled=grey). I want to change this behaviour. I want to set the forgeground color of disabled components to the same color as a enabled components. Is there a simple solution to solve that?

[kirill-grouchnikov]

There's no top-level API that would reconfigure an existing skin to do this, and it doesn't sound like something I'd want to have out of the box. By foreground, do you mean text, checkmark, or maybe the entire checkbox (border and fill included)?

Reconfiguring the visuals of the disabled state has a couple of APIs:

• Passing an explicit disabledScheme as the third parameter to RadianceColorSchemeBundle for the default or any other decoration area. If you pass the same scheme as enabledScheme, all disabled controls will look the same as enabled
• Calling RadianceColorSchemeBundle.registerAlpha() API for ComponentState.DISABLED_UNSELECTED and ComponentState.DISABLED_SELECTED. This will control the amount of alpha applied to the disabled state and all its visuals (fill, border, text, marks, arrows, etc)
• Calling RadianceColorSchemeBundle.registerColorScheme passing the color scheme, association kind (such as MARK or MARK_BOX), and component state (such as the disabled states from the last option). There is no association kind for text, so this can't be used to control the visuals of the text separately from the rest of the component

It would help to see a screenshot of the proposed visuals to provide a more targeted answer.

[imrohl]

Thanks for your fast response! Currently we use the very basics of radiance and even after taking a further look onto the documentation i do not understand how to implement your aproaches.

We are separating viewing data/editing data on the gui. But we are using same components to implement that (TextFields instead of Labels for the sake of selekting etc.) Therefor we are disabling components for viewing. But CheckBoxes and RadioButtons are displayed as disabled. My goal is that these both behave like disabled components, the checkmark must also be disabled, but the text (label as well as tooltip) should be displayed normally (enabled).

[kirill-grouchnikov]

I think the simplest here would be to use a text-less radio button (marked as disabled) with an enabled label right next to it. Then you set the tooltip on the label, and that would be displayed as enabled as well.

I'm not necessarily agreeing that this is a good user experience, as that would break my own personal expectation of how disabled controls should look like.

[imrohl]

Thats fine for me ;) Its not nessesary that you have got the same opinion regarging user experiance like me. So there is realy no chance to solve my issue with radiance itself and i have to work around? Back to your first suggestion: Do you have entrypoint/example how to configure/implement an individual color scheme based on an other color scheme and apply it to the application?

[kirill-grouchnikov]

There is no API at the moment to configure the text part of a disabled radio button to look enabled. There are APIs mentioned above to configure the markbox and the mark of disabled controls (radio buttons and checkboxes) to use a different appearance from the text. However, these are all targeting the scenario where application wants to have its own fully custom skin, and be in control of configuring every aspect of that skin.

There are no APIs, no do I have anything planned at the moment, for taking an existing skin and reconfiguring smaller parts of it like what is being discussed here.

[imrohl]

Ok, thanks or your help anyway!

To provide more flexibility maybe it is possible for future developments that you devide the component UIs into smaller methods and make them at least protected. That would give devs the oportunaty to extend these UIs easily. For example RadianceRadioButtonUI#paintButtonText. If this method were protected i would be able to override it.. Now i must copy/paste the whole class / fork the repo / find an other workaround.

[kirill-grouchnikov]

No plans to make UI delegates be part of the official API, which is why they are all in the internal package, subject to change and move at any point in time.