Page MenuHome

Make enum menus nicer
Open, Needs Information from UserPublic

"Love" token, awarded by ixd."Love" token, awarded by jonathanl."Love" token, awarded by Mets."Dislike" token, awarded by Regnas."Y So Serious" token, awarded by hitrpr.
Assigned To
Authored By


Enum menus in Blender have a few issues:

  • Title is at the bottom
  • Selected item is redundantly duplicated both inside the menu and outside
  • It's not easy to see which item is the active one when the menu is open

We can solve this by changing the way we display enum menus.

  • Rather than popping up or down, they can pop outwards from the selected item
  • Add a checkmark to the currently selected item
  • Put title text always on top

Like so:

This only applies to enum menus, not popovers or regular dropdown menus.


To Do

Event Timeline

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 (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:

@Regnas (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.

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



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 (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.

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.

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.

  • This wont work well for enums at top/bottom window bounds:

    This is an issue in the default layout for:
    • top-bar orientation w/ transform tool.
    • outliner display modes
    • render window view/slots/channels.

      Of course it can be worked around, it just adds a small penalty to doing something that currently has none.

      Most likely the workarounds involve clamping the menu or switching to different behavior - which will feel like workarounds (from a user perspective), making the UI more awkward by default.
  • Adding a check mark means we will need a check-mark and an icon? (for icon only buttons we want to be able to see the icons too).

    Having two columns for icons may look a bit odd too.
  • Assume this isn't expected to be used for multi-column enums, are there other cases this wont be used?

General note, this is more a design task than a paper-cut.

Campbell Barton (campbellbarton) lowered the priority of this task from Normal to Needs Information from User.Mar 12 2019, 1:14 AM

@Campbell Barton (campbellbarton) 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.

William Reynish (billreynish) raised the priority of this task from Needs Information from User to Normal.Mar 12 2019, 12:36 PM

@William Reynish (billreynish) 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?

@William Reynish (billreynish)

On all your screenshots shows native macOS pop-up menu, and it works well and is familiar to users. Although 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.

Campbell Barton (campbellbarton) lowered the priority of this task from Normal to Needs Information from User.EditedApr 19 2019, 1:02 PM

Issues raised here T62309#638681 should be addressed by design, making as incomplete.

We could either:

  • A: Only do this if there is space
  • B: Simply offset the menu there isn't enough space
  • C: Accept that it can go off screen and show arrows inside the menus just like we do in the pulldown menus when they are out of bounds.

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 Acheson (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.

...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 Acheson (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.

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.

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 Van Lommel (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 @William Reynish (billreynish)'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

I see some problems here.

  • The "dot on the right" is already used in the interface.

  • The position of the indicator on the right does not work well in the case of a wide menu.

As an option, Windows-like behavior may be used.

  • When you click and the menu opens - the current item is highlighted, you can easily see it.

  • Until you hover the mouse over the menu item.

  • If the cursor moved out, the current item is highlighted again.

@Yevgeny Makarov (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.

@William Reynish (billreynish) - 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.

@Brecht Van Lommel (brecht) : 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.

any issues with empty space
I think the empty space looks pretty bad

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, 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.

@Brecht Van Lommel (brecht) : 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:

Menus in the Windows 10 Settings work 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".

Leha (leha) added a subscriber: Leha (leha).EditedJun 23 2019, 7:15 PM

Windows also uses dots and checkboxes in Explorer

@Yevgeny Makarov (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:

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.

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:

For comparison, this is using a dot on the right:

And this is with dot on the left:

@Harley Acheson (harley), Not trying to be nosy but I think it would be better with just a thin outline and the highlight color.