Page MenuHome

UI: Various Widget State Changes
Needs ReviewPublic

Authored by Harley Acheson (harley) on Jul 5 2019, 1:32 AM.

Details

Summary

The following changes various visual coloring and effects that are based on widget state.

Default Dialog Buttons

Buttons can have a flag set with UI_BUT_ACTIVE_DEFAULT to indicate they are the default button among a group. The button executed if just pressing "Enter". For example the "Save" button on the "Do want to save?" dialog.

Unfortunately the way that indication is currently drawn has a few problems. The color is based on the "Inner Selected" of "Menu Item", which is not intuitive to find. The color will usually look muddy since it is 50% mix of that color and the regular color. And the bend radius of the corners is hard-coded. So if you change the roundness of the buttons the corner will not match. For example you can see this if you make the buttons more or less rounded:

This patch fixes those problems and also makes the button the full color of that widget's "Inner Selected" to better indicate its state. Top showing current color when using default theme, the bottom after this patch is applied:

Disabled Pulldown Menu Items

Some menus items are disabled when not applicable. In the following example, "Revert" is disabled because there is nothing to revert at the moment. You will notice that it properly looks enabled when you are not hovering over it (leftmost image). But when hovering the text becomes bright and the background takes some of the "selected" color. It isn't becoming even part-way selected so should not use that color nor become brighter. This patch makes it look like the right-most image:

Enum Lists

Although we use pulldown menu code for enum lists, it is best if we deviate from that behavior for popup enum lists. The current-selection option should look as enabled as any other of our widgets when on, enabled, or selected. This patch makes it change from the behavior shown the left to that shown on the right. It more clearly shows the current value and feels intuitive while selecting. Active state (pressed down) takes on the brighter selected color (not shown):

Hover State

This patch also makes subtle changes to how widgets look when you hover your mouse over them. Currently it is a bit arbitrary what is highlighted and what is not. And the effect varies a lot with widget color. This patch makes more things show a hover highlight and that highlight changes the inner color, outline color, and the text color. All in a more pleasing, but still subtle way, that is a bit more uniform and predictable.

Diff Detail

Repository
rB Blender
Branch
arcpatch-D5187 (branched from master)
Build Status
Buildable 4300
Build 4300: arc lint + arc unit

Event Timeline

Design wise seems reasonable to me, but no time to review it right now.

Changes:

Enum Lists (and popovers) share widget colors with menus (pulldown and popup). This can cause some problems when an enum list must pop up on top of a popover as you cannot tell where one starts and where the other begins.

This patch adds a little contrast to the enum lists.

The following image shows the Outliner Filter popover. The left and middle shows the Objects list before and after it is opened. It is difficult to tell where the object list is as the colors are all too similar. The right shows how it looks after this patch with just a minimum amount of contrast added to make it more visible.

Some small tweaks and have also combined the changes from https://developer.blender.org/D5135 because both patches effect some of the same code parts. Nice to see them together.

So on the capture below you see the change in category titling along with current item and hover highlighting:

@Brecht Van Lommel (brecht) : thought I'd add a brief summary here, just because this patch does a few different things. We might want them all, none, or tweaks.

The patch changes Enum lists so that the currently-selected item is the most highlighted, with secondary highlight going to the mouse hover. It also removes the title from enum lists that have categories, and adds a rule in between the category and content. You can see all these things here:

It properly handles multi-column lists where a column overflows. Here showing "Polish" in the next column nicely:

Disabled dropdown items are currently showing with bright text on hover. This patch keeps it looking disabled while hovering:

The patch makes changes to the way that widgets highlight on hover. Because it involves background, icon, and border, it makes more items show a highlight in a more consistent way:

This patch also makes it so default buttons, like the "Save" on the quit dialog, show a highlight in full color rather than the muddy in-between we show now:

And lastly, Enum lists get their theme styles from menu, as does many other things like popovers. But sometimes we show enums on top of popovers so it is hard to tell one from the other. For this patch I add a bit of contrast to make it easier to tell where one starts and the other begins.

These changes look good to me.

Sync with master, silence GCC warnings.

This raises some issues.

Some menus don't work (which previously didn't look any different). Object Mode for example.
All other menus don't work like this - the ID selector, tool selector, regular menus.

Personally I think we could not have the different hover and active state, and just highlight it blue when the mouse is over it.
This is what ID selector currently does and it works OK.
We get nearly all the advantages without having this second kind of hovering.
Otherwise it means there is an obvious difference that feels inconsistent.

Or, it could be changed everywhere - which could be OK too but will take more time.

@Campbell Barton (campbellbarton) - Personally I think we could not have the different hover and active state, and just highlight it blue when the mouse is over it.

Yes, when I was playing with this last it did seem to feel fine and make sense when the same highlight is used for both hover and selected. And you are right, it would result in some more consistency.

Or, it could be changed everywhere - which could be OK too but will take more time.

Will take a look at this too, in case I can make them all consistent in reasonable time (and with my limited knowledge LOL).

Let me play with it a bit a bit more.

Thanks for taking a look!

Hey @Campbell Barton (campbellbarton)!

Okay, I might have changed my mind a bit from my last comment. LOL...

Personally I think we could not have the different hover and active state, and just highlight it blue when the mouse is over it.

The behavior I am trying to introduce here for enums, with selected in BLUE and hover showing a lesser highlight, is used all over right now. So I'm not really adding inconsistency, but reducing it.

So just in the 3D view: Transform Orientations works exactly like this now. As does Pivot Point, Snapping, Proportional Editing.

These buttons are the same: Default selected one in blue, hover in a lesser highlight

Seeing these other things it just seems logical that enums would look like these. And making all these other things use the same highlight for hover as for selected would be much more work and introduce even more changes.

But that does bring us back to the Object Interaction Mode menu. I just can't see why that one out of so many is different from the rest. Can you give me any hints on what thing is? If not I'll keep on digging...

Thanks for any help or suggestions,

Harley

Hmmm.... can see things like the "Object Interaction Mode" menu being made in uiItemsFullEnumO() with items from uiItemsFullEnumO_items(), but can't see a way of getting the current value.

Broke a couple things out of this patch since they are unrelated to the one change that is contested: