Command with secondary content model shown as selected

[FRvanderVeen]

I was wondering if the following is possible:

In my ribbon I have a command that has a secondary content model. Under a given condition I want that button to display as "selected". Similar to what one would do if it was a Command with setToggle.

What I have so far is this:

The Command with the 0 is configured as:

Command.builder().setText(...).setIconFactory(...).setToggle().setAction(a->{}).setSecondaryContentModel(...).build()

The Command with the 2 is configured as:

Command.builder().setText(...).setIconFactory(...).setToggle().setAction(a->{}).build()

I want the 0 Command to look like the 2 command.
Preferably the Command isn't a toggle, because I only want it to open the popup. The selection is to inform the user that something inside the secondary content model is "active".

[kirill-grouchnikov]

This isn't possible at the present moment. There is no concept of a "synthetic" state bit that can be added to existing components.

The concept of custom component state facets is mentioned in the documentation, but it requires explicit "collaboration" of the component that defines such a facet and handles state updates, the UI delegate that queries the skin for the color tokens bundle that matches such an extended component state, and the skin that registers custom color tokens bundle(s) for that extended component state.

I do have a vague idea of a longer term plan to revisit how component states are constructed today. Today they are an enum-ish API surface that aims to capture multiple state bits, such as ROLLOVER_SELECTED, in its internal on/off component state facet arrays. This isn't scaling well for a more finer-grained skin definition (and the matching querying in all the UI delegates). It also mixes two rather distinct bits:

• Content state bits, such as enabled vs disabled, selection, or determinate vs intedeterminate
• Transient interaction bits, such as rollover or pressed

At some point down the line I do want to experiment with revisiting the current approach and make it more flexible, which would also include support for application specific component state bits - like the "active" bit that you're asking for here. But this isn't going to happen for a while, as it's going to be touching a lot of the code, and there needs to also be a clear "win", so to speak, in terms of the mental model and cognitive reasoning about how Radiance approaches this.