UI: Replace UI_ACTIVE with UI_HOVER #112160

New Issue

Harley Acheson · 2023-09-08T20:22:21+02:00

Harley Acheson commented

2023-09-08 20:22:21 +02:00

UI items that are actively hovered are given a UI_ACTIVE flag so that they can shown highlighted. This is a confusing name for this state, and most people would not guess this means hover. We also use the term "Inactive" in our flags (UI_BUT_INACTIVE) with an entirely different meaning. So a button can be both inactive and active, with different meanings.

I think we should move toward a more standard definition of states. Probably taken from HTML since their terms are well-researched. So "Hover" would be used to indicate the state of having a mouse over the item. "Active" would indicate that an item is being directly acted upon, like a button that would be shown as depressed because you are clicking on it right now.

The first step of cleaning this up would be renaming UI_ACTIVE and its uses. There are some functions that should also be renamed, but others not. One that changes colors based on this should use "hover", but we also have functions that "activate" buttons and these usages are correct. So changes must be done carefully.

UI items that are actively hovered are given a UI_ACTIVE flag so that they can shown highlighted. This is a confusing name for this state, and most people would not guess this means hover. We also use the term "Inactive" in our flags (UI_BUT_INACTIVE) with an entirely different meaning. So a button can be both inactive and active, with different meanings. I think we should move toward a more standard definition of states. Probably taken from HTML since their terms are well-researched. So "Hover" would be used to indicate the state of having a mouse over the item. "Active" would indicate that an item is being directly acted upon, like a button that would be shown as depressed because you are clicking on it right now. The first step of cleaning this up would be renaming UI_ACTIVE and its uses. There are some functions that should also be renamed, but others not. One that changes colors based on this should use "hover", but we also have functions that "activate" buttons and these usages are correct. So changes must be done carefully.

👍 2

Harley Acheson added the

Type

Design

label 2023-09-08 20:22:21 +02:00

Harley Acheson added this to the User Interface project 2023-09-08 20:22:22 +02:00

Julian Eisel commented

2023-09-13 13:27:41 +02:00

UI_ACTIVE should indeed be named UI_HOVER (or better UI_BUT_HOVER/UI_BUT_HOVERED?), this has been noted and agreed on a few times in the past, we just never actually made the change. This is a simple first step, let's do it.

Think UI_SELECTED could/should be UI_ACTIVE but changing that can cause confusion with the other uses of "active". Also code comments may still refer to what's now called hover and may be misleading then. It's a bit tricky to make this transition. All things considered I think this should be called UI_PUSHED (or UI_BUT_PUSHED) instead.

UI handling code uses the word "active" but it's a bit ambiguous too, since it involves both the hovered and the UI_SELECTED/UI_PUSHED state and potentially others. I suggest we consider this state "focused" instead. In blender hovering a button can mean that it becomes focused, this makes sense to me.

`UI_ACTIVE` should indeed be named `UI_HOVER` (or better `UI_BUT_HOVER`/`UI_BUT_HOVERED`?), this has been noted and agreed on a few times in the past, we just never actually made the change. This is a simple first step, let's do it. Think `UI_SELECTED` could/should be `UI_ACTIVE` but changing that can cause confusion with the other uses of "active". Also code comments may still refer to what's now called hover and may be misleading then. It's a bit tricky to make this transition. All things considered I think this should be called `UI_PUSHED` (or `UI_BUT_PUSHED`) instead. UI handling code uses the word "active" but it's a bit ambiguous too, since it involves both the hovered and the `UI_SELECTED`/`UI_PUSHED` state and potentially others. I suggest we consider this state "focused" instead. In blender hovering a button can mean that it becomes focused, this makes sense to me.

Julian Eisel referenced this issue

2023-10-24 17:12:26 +02:00

UI Code Quality: Rename `UI_ACTIVE` button flag to `UI_HOVER` #114113

Julian Eisel commented

2023-10-24 17:29:40 +02:00

Thinking further about this, I think UI_HOVER_FOCUS is a reasonably good name. PR: #114113

Adding the term "focus" seems important because the button will receive events and shortcuts, a rather unique Blender feature. Otherwise the flag seems too much like a drawing flag, but it actually makes a button "active" for the event handling. Plus sometimes we set the flag for buttons to be focused, without actually mouse hovering it. Lastly a button may be hovered but not highlighted/focused/active because another (modal) handler is blocking it. I'd still include the term "hovered" since this is an important hint.

Interestingly, I found this new terminology helped me think more clear about some existing code and find potential improvements :)

Updated terminology proposal:

UI_ACTIVE -> UI_HOVER_FOCUS: See above.
UI_SELECTED -> UI_PUSHED: See previous comment. Or: UI_PUSHED_FOCUS?

Handling code can keep the term "active" for the button it sends input to, this seems reasonable. But we could also rename it to focus (if we go with UI_HOVER_FOCUS & UI_PUSHED_FOCUS?).

Thinking further about this, I think `UI_HOVER_FOCUS` is a reasonably good name. PR: #114113 Adding the term "focus" seems important because the button will receive events and shortcuts, a rather unique Blender feature. Otherwise the flag seems too much like a drawing flag, but it actually makes a button "active" for the event handling. Plus sometimes we set the flag for buttons to be focused, without actually mouse hovering it. Lastly a button may be hovered but not highlighted/focused/active because another (modal) handler is blocking it. I'd still include the term "hovered" since this is an important hint. Interestingly, I found this new terminology helped me think more clear about some existing code and find potential improvements :) --- Updated terminology proposal: - `UI_ACTIVE` -> `UI_HOVER_FOCUS`: See above. - `UI_SELECTED` -> `UI_PUSHED`: See previous comment. Or: `UI_PUSHED_FOCUS`? Handling code can keep the term "active" for the button it sends input to, this seems reasonable. But we could also rename it to focus (if we go with `UI_HOVER_FOCUS` & `UI_PUSHED_FOCUS`?).

Julian Eisel referenced this issue

2023-10-24 17:35:03 +02:00

UI Code Quality: Rename `UI_ACTIVE` button flag to `UI_HOVER` #114113

Harley Acheson commented

2023-10-24 20:08:41 +02:00

Although we don’t deal with this state much now, I’d prefer to keep a separate “focus” state, the single item that would receive keyboard input. In most applications we not only enter this state by clicking on an input field, but change the focused item with the Tab key. In Blender we do indicate this state for text inputs but we should do so for others. For example press Tab to move to the next item which is a checkbox, which changes in some visible way to indicate focus, press space bar to toggle its state, then hit Tab to move to the next.

Similarly, close Blender with unsaved changes and we get a dialog. We could better show the current “default” button with focus indication (usually an outline), then you could Tab between the buttons and press Enter.

Another thing I’d love to separately support is a (proper) “Active”. The item in this state is currently being actively acted upon. Typically this is the “Down” position of a button when you are depressing it. Checkboxes might show an inbetween state. It helps interfaces feel a bit more alive and responsive. It also visually explains the behaviour when you click to depress a button, but the drag out of it before releasing, therefore cancelling the action.

Together you might press Tab to move focus to an item. Move your mouse over another item and it gets “hover” while the first is still “focus”. Press down on your mouse and the new item gets focus and active. Release the mouse button and active is removed but focus remains there.

Although we don’t deal with this state much now, I’d prefer to keep a separate “focus” state, the single item that would receive keyboard input. In most applications we not only enter this state by clicking on an input field, but change the focused item with the Tab key. In Blender we do indicate this state for text inputs but we should do so for others. For example press Tab to move to the next item which is a checkbox, which changes in some visible way to indicate focus, press space bar to toggle its state, then hit Tab to move to the next. Similarly, close Blender with unsaved changes and we get a dialog. We could better show the current “default” button with focus indication (usually an outline), then you could Tab between the buttons and press Enter. Another thing I’d love to separately support is a (proper) “Active”. The item in this state is currently being actively acted upon. Typically this is the “Down” position of a button when you are depressing it. Checkboxes might show an inbetween state. It helps interfaces feel a bit more alive and responsive. It also visually explains the behaviour when you click to depress a button, but the drag out of it before releasing, therefore cancelling the action. Together you might press Tab to move focus to an item. Move your mouse over another item and it gets “hover” while the first is still “focus”. Press down on your mouse and the new item gets focus and active. Release the mouse button and active is removed but focus remains there.

Julian Eisel referenced this issue from a commit

2023-10-25 18:36:38 +02:00

UI Code Quality: Rename `UI_ACTIVE` button flag to `UI_HOVER`

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

UI: Replace UI_ACTIVE with UI_HOVER #112160