Make enum menus nicer #62309
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
19 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#62309
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Enum menus in Blender have a few issues:
We can solve this by changing the way we display enum menus.
Like so:
{F6779303, size=full}
This only applies to enum menus, not popovers or regular dropdown menus.
Added subscribers: @WilliamReynish, @CharlieJolly, @schweppie, @Hexbob6, @freemind, @PierreSchiller, @SteffenD, @remotecrab131, @Thane5, @orvb, @brezdo, @iss, @0o00o0oo, @ideasman42, @RamiroCantu, @Regnas
I still prefer the current universal standard way of opening this menus. I can open and close the menus just by clicking, without having to move the mouse away to dismiss the popup, unlike this new method (I can see this becoming very annoying when you're searching for something in those menus)..
I hope this can be made optional, otherwise most people may think this is a bug.
@Regnas I don't know if you've used enum menus like this in other apps. This is a standard way to do it.
With this design, you can indeed just open it and release, and it will fall back to the last selected item if you don't wish to change it.
I don't understand what you mean about it being a bug.
Here's a screen recording for reference, for users who have never seen standard enum menus:
enum_menus.mov
@Regnas Just checked a few random apps. They all work this way. So I don't know what you mean re. 'standard universal way' considering that this seems to be quite standard.
Added subscriber: @DuarteRamos
I guess you're on a different operating system. This is not how it works on Windows, which is the most popular Operating System.
Few examples:
Substance Painter
Keyshot
Photoshop
Cinema 4D
After effects
Marmoset Toolbag
Opera Browser
This very own website ?
I personally don't think this task is an improvement, so please make it optional or platform specific if possible.
Here's what I see:
Anyway, this task solves the issue of the title being at the bottom, and has the other advantages mentioned too, even if Microsoft Windows does its own thing.
Luckily, we don't particularly follow UI standards of Microsoft Windows , which doesn't even have very well defined UI patterns to begin with. See for example the fact the Blender doesn't have a Start menu, nor does it use the Ribbon, or blue screens when it fails.
Instead, our UI is cross-platform, and we try to use the best ideas to make the nicest UI we can.
This is operating system specific, and that would be the best way to implement such feature, or at least an option in the preferences.
I used some apps with this behavior before and it always felt like a bug. The menu is all over the place, changing position to display the last selected etc...
Not efficient at all.
@Regnas: There's nothing less efficient about this - on the contrary, it's faster to move up and down to the next item in the list. With the Windows method, you have to start from the top of the list every time it's opened.
Again, our UI is shared across OS's, and isn't designed to follow Windows UI guidelines specifically.
Added subscriber: @brecht
For muscle memory it can help to always have a particular item at the same distance, so that you can move there without reading the labels. If that distance is different every time it can be less efficient as you reorient yourself, even if the distance is shorter. Not sure how much difference this makes in practice.
Added subscriber: @ThinkingPolygons
Please don't.
Maybe as an option in the preferences to satisfy the Mac users.
Please, let's not forget which OS the majority of blender users use, before applying such radical change. ?
I like my menus always in the same place and not covering the button, just like it is now.
So yeah, optional please.
The goal is obviously not to 'satisfy Mac users'. We don't use Mac-style menu bars and other things like that either.
Instead, the goal is to solve the issue of the title being at the bottom currently.
Also, this way of doing enum menus has a number of advantages: They are faster to navigate and clearer too.
Given that these type of menus also exist in some Windows apps, I think that Windows users can figure out how to use these menus too.
Of course it can be worked around, it just adds a small penalty to doing something that currently has none.
General note, this is more a design task than a paper-cut.
@ideasman42 Just like we do for other menus, they should be offset when you reach the edge, so menus never exceed the edge of the window.
@WilliamReynish OK but this will be a awkward for situations where it's always clamping to window bounds with enum buttons on headers.
Design proposals should not only describe the "happy path", they should also describe drawbacks and intended behavior in those cases:
For eg, with header enums is this what your suggesting?
Currently if you click twice, it opens then closes the enum. With this new behavior the outcome of clicking twice depends on the previously selected item and the location of the button relative to the window bounds. Is this intended too, or can a design be made which has a more predictable outcome?
Added subscriber: @jenkm
@WilliamReynish
On all your screenshots shows native macOS [pop-up menu ]], and it works well and is familiar to users. Although [ https:*developer.apple.com/design/human-interface-guidelines/macos/buttons/pull-down-buttons/ | pull-down menu are also used depending on the context.
Since Blender has menus in each editor, popovers, data-block menus... (which opens down), it is likely that enum menus should open downwards as well.
Title is at the bottom. In the vast majority of cases, this title is not needed at all, since there is a label next to the button. The active item should be just grayed out.
Issues raised here #62309#638681 should be addressed by design, making as incomplete.
We could either:
Added subscriber: @Harley
Personally I think you should separate the problems with the current design from the visual differences between Mac and PC.
You mentioned two specific things.
The title at the bottom does look dumb. I think it could be simply removed, no matter where it is. You click on this menu element to change a setting; you know what it is before you click on it.
They don’t show the already selected option. True, but I think we should indicate that with a colour change for the background of that item. Check marks for us are problematic since items can start with icons. But that is possible too if we just slide the content to the right to make room.
I just think we can address the major issues without having to change the direction and position of the menu.
Yes, it’s true, we can solve some of the issues without changing the direction in which the menu opens.
But if we want to keep the header text, the ‘open outwards’ concept works better.
It’s also, IMO, just nicer in general. Currently, if you have a long list of options, the way menus work now means you have to always start at the very top every time you open it. With this proposal you always start from the last selected item.
I might take back my earlier comment about using color or sliding the content to the right.
Enum menus don't have submenus, so we could just use the space on the right to indicate which is currently selected:
@Harley: That could be a nice little improvement, although why put it on the right? Seems like it might be slightly easier to read on the left, next to the text.
Could go on either side really. I'm not overly concerned either way, but do prefer it on the right in this case. Possibly because the indication of current selection is a little less important. It is good information to know but it is quite optional as it does not really inform the new choice. If anything the current selection is less important than the others, so needs indication but not extra weight.
Here are the two ideas side-by-side. Again, both work, but I find the left a bit neater, cleaner, quicker to read what is important. But I don't care too much.
@Harley it's funny because I find the one on the right clearly easier to see. With the left one, it's a bit hard to see at a glance which item was the selected one.
In any case, both of these would be a slight improvement I think.
Added subscriber: @hadrien
I agree that having enum items jump positions depending on which one is currently active does not seem desireable (what Brecht says), but I have no experience using this, am only judging from the captures provided above. An indicator however would be most welcome, either in the form of a checkmark or a dot at the rightmost edge of selected enum item, or a different background color.
Added subscriber: @KalyanS
IMO the check for selected item should definitely be added, and to the left of the text. I believe popup location and title location should be kept the way it is, or made available as a non default option, however I wouldn't really mind much if the macOS pattern is made standard
I'm on Windows, and distance muscle memory is a good point by @brecht.
But in practice, I can't really say I rely on the distance much, especially when I see these menus frequently flipping top to bottom based on where they are in the screen.
What's more important to me is the order of items.
So I'm interested to see how @WilliamReynish's proposal works in practice. It looks like it could be useful.
Well, this design makes it easier to make predictable relative changes. Going to the next item in the list always requires the same mouse travel distance.
Overall mouse travel distance is bound to be less, because if you have a long list and want to access items at the bottom, you won’t have to repeatedly move all the way to the bottom each time you open the menu.
I can commit (fairly quickly) a patch that will (just) highlight the currently-selected item with a dot on the right, as shown below, so you can play with it and see if you like it.
It doesn't change how the menu opens, just adds the current item.
Why on the right? It is mostly just my laziness in the way we draw these things. To be on the left we have to know ahead of time and shift everything right. This way it is just a decorator for the one item
Here you go...
https:*developer.blender.org/D5117
I see some problems here.
As an option, Windows-like behavior may be used.
@jenkm - I certainly agree with the wide menus. And it is even worse when the menu wraps into multiple columns as the indicator looks more connected to the following column. However, I'm not a fan of having the indication only when not hovering in the area. It is while your mouse is in the area that I want the indicator the most.
@WilliamReynish - here it is with ICON_DOT and on the left. It seems quite nice. The only time it bothers me is with the "Editor type" menu with the misalignment of the headers. I think those columns just need a separator line like we have in the other examples.
Personally I things the Windows like behavior is quite good, doesn't have any issues with empty space or multiple columns, and it's convenient for arrow key navigation to the next/previous item.
It could very well be that I am just not understanding something about that proposal as I can't see how any of these ideas help, hinder, or involve next/previous behavior.
So again, I am probably just missing something. Although described as “windows-like” I have yet to find anything on Windows like it, but only examples to the contrary with permanent indicator to the left of the item. The proposal above seems to show the information briefly then it make it disappear when you actually use the menu. And the proposal mentions showing it again when you have your mouse out of the menu area but that is when the menu will get dismissed.
You really just mean the extra padding on the left of the non-current items? Is there really an issue with empty space on a temporary popup window? For menus without icons there is less padding added than what we add for icons. And for those already with icons it adds very little extra padding.
All variations are worth exploring of course, and I certainly enjoy that. But I think I am just not understanding some of that proposal nor any objections to [D5117 ](https://developer.blender.org/D5117), which in practice looks and feels quite natural to me. But its only a little thing and no worries if others don't agree. Lots of other things to do and have fun with
Menus in the Windows 10 Settings work like this: the current item is highlighted in blue (without a checkmark), and pressing the up/down key goes to the previous/next value relative to the current item regardless of where the mouse position is. This is more similar to a typical active item in a file browser or outliner with associated arrow key navigation.
If we need to make extra space in menus for a checkmark, or add more clear column separators, it's not a big problem but to me it just a looks a bit ugly.
Hey, "ugly" is a big problem and a great reaction. But always more interesting in what gives that reaction. If it is just the extra padding then that can can be lessened as well.
Having the indicator on the right also had no impact on the padding and no conflict with existing icons. But William doesn't like it as much that way. And it gets confusing as to what is being marked when showing multiple columns. But yes, we could address that with a column separators if you preferred them on the right like this:
Oh, those ugly flat mobile-like apps on Windows 10. Those don't behave as described above. The current-item always remains, not removed when you hover over the menu. Here is a capture to stare at. When opened we can see the current selection is "Landscape" and that highlight remains as I mouse around, with the hover showing the darker grey.
We could do something like that too, have some other row indicator showing current value. Although we are, by default, showing a very strong indicator for mouse hover so it would look reversed from above capture. And if we did ever treat that as keyboard selection index it would look funny to hit down arrow and move the less-strong indicator. So we'd probably have to reverse this. Here with default theme:
This JS demo works like what I meant by "Windows like".
http://jsfiddle.net/gL9cx0nk/
Added subscriber: @Leha
Windows also uses dots and checkboxes in Explorer
@jenkm : Thanks! That does explain it much better. Or I am just thick and needed it dumbed down. LOL
But that (exact) implementation still loses the highlight of currently-selected as you hover into the area. Could get a bit ambiguous when you hover over a new item but then pull off to the side, as the menu would dismiss but your last selected item would not be chosen. It also doesn't work well for Brecht's desire to (eventually) allow changing selection using keyboard up/down.
For this type of solution, where we highlight the entire row, I think it requires that we have two classes of highlight: one for hover and another for selected. And in this case we probably want primary highlight on selection and secondary on hover. Which is exactly how we have the Outliner right now.
What did you think of that last suggestion? Is it close enough to yours that you like it or no? Is there something in between, etc? That would be this one:
Added subscriber: @jeacom
I have to agree, muscle memory play a big hole in the blender's workflow, many users expect the interface to be consistent, making enums jump around defeats the purpose of having a more friendly interface.
Speaking anecdotally the swap from plain to pie menus was a big muscle memory scrambler. luckily it was easy to recover since the menus don't jump around, imagine how it would be if every time we press tab, the mouse stay on top of the last selected mode... ew.
Hmmmm.... in practice it doesn't feel weird to use the same indication for both hover and current value:
It looks funny in the capture but feels quite logical at the time you are doing so. You should give it a try:
EnumCurrentActive.diff
For comparison, this is using a dot on the right:
EnumCurrentRight.diff
And this is with dot on the left:
EnumCurrentLeft.diff
@Harley, Not trying to be nosy but I think it would be better with just a thin outline and the highlight color.
Added subscriber: @RayMairlot
Changed status from 'Needs User Info' to: 'Confirmed'
Removed subscriber: @Thane5
Added subscriber: @RedMser
Removed subscriber: @brezdo
Removed subscriber: @Hexbob6