mame/ui: Deemphasized default configuration values

[holub]

Similar to "Audio Effects"

This PR brings more gray if configuration value is using default

[holub]

Oops... in "Audio Effects" gray means unavailable, not default. What should we do to default then?

[holub]

I'm personally think that if majority of the values on the right have the same colors as a name on the left, it gives less pleasant experience compare to suggested above where defaults are gray

and now:

[holub]

After brainstorming with @MooglyGuy suggesting following:

• disabled elements are dimmed to 40%
• defaulted - 70%

[cuavas]

If you’re going to do this, it needs to be consistent across everything, and the most significant place where that currently dims non-inherited values is the input assignment menus, in src/frontend/mame/ui/inputmap.cpp (which means the audio menus, which show the opposite behaviour, are really annoying).

Also, you’re changing just a couple of places to use your new “at default” display hint flag, while there are a huge pile in the audio effects menus still using FLAG_INVERT.

FLAG_INVERT is poorly named, since it doesn’t actually invert things, it de-emphasises them – it’s also used to de-emphasise clones on the system selection menu, and to de-emphasise disabled items in a couple of places (audio effects menu and video options menu that I can think of).

This creates a confusing situation where these disabled (and hence unselectable) items aren’t visually distinct from items with their default values.

There’s also a semantic issue with the input assignment menus where it only checks whether the current assignment is equivalent to the inherited value for deciding whether to de-emphasise the value. But there’s a distinction between an inherited value and configuring the value to be the same as the value that would be inherited: in the former case, changing the value at the next level up will cascade; in the later case, it won’t.

I don’t know whether it’s worth having an extra flag for “at default” as well as the de-facto “de-emphasise” flag (which should maybe be renamed to better reflect what it does).

One idea to visually distinguish disabled items would be to de-emphasise the text on the left as well as the text on the right. The trouble with doing this is “disabled” items are used pretty frequently for information text. Maybe making these a separate item type would be a solution to that.

Anyway, it’s a pretty deep rabbit hole. But this PR in its current state doesn’t make things more consistent, it amplifies the existing inconsistency by spreading the “de-emphasised means default” from the audio effects menus to other menus, and implementing the de-emphasis in an inconsistent way.

[holub]

Thank you Cuavas for the review!
That not the first rabbit hole I'm jumping into... I like idea to de-emphasize item in case of disabled... I implemented it. Now we don't need to drop disabled items to 40% (which bothered me) and can stay at 70%, just disabled have item and subitem dimmed; de-emphasized - only subitem.
I also dropped comment in pluginopt about string flag which I confused about.

The current state look like this:

[holub]

need directions here

[galibert]

I think we need to change the menus to use some kind of FLAG_INHERITED, FLAG_DEFAULT, etc and leave the presentation to the menu code.

[cuavas]

Since it's probably better to do the painful part of the change when we're also changing the runtime libraries and system requirements on Windows, 39b2d1c rationalises what we have with minimal impact, and also fixes the semantic bug that I mentioned on the input mapping menus. It also modernises the code there a bit, using std::variant rather than nasty pointer casts.

Changing it to use semantic flags, updating the presentation code and so on is a much bigger task that requires more thought.

[cuavas]

Oh, and I'm going to have a hard time getting used to the new behaviour of the input assignment menus. It's being changed after decades with the old behaviour. I expect it's going to confuse plenty of other people as well.

[holub]

I'm sad I hadn't been able to deliver this without having you involved, but glad you were motivated.
few leftovers in #15283