Page MenuHome

UI: Collapse Enum Menus to Single Column
Needs ReviewPublic

Authored by Harley Acheson (harley) on Dec 5 2019, 12:06 AM.
Tokens
"Love" token, awarded by jmztn."Love" token, awarded by HooglyBoogly."Like" token, awarded by Tetone."Like" token, awarded by duarteframos.

Details

Summary

The Enum menus can have multiple columns, either because they are too long or because they have categories. Unfortunately they can become too wide to fit in their available space:

Shown here with the Languages list not fitting within the default width of the Preferences window:

Shown here with Editors menu not fitting within a torn-off window:

The following patch estimates the width of the menu, and if too wide will show it a single column.

Result here of Languages menu:

Result here of small torn off editor window:

This does constitute a bit of a refactor of this code. The existing code has a section where columns and rows are estimated but does not do a good enough job for this purpose. For example the list of Editors is estimated to be only two columns despite being four categories.

I have tried to keep it as simple and logical as possible. But this patch does incorporate the changes in https://developer.blender.org/D5135 as those changes are generally liked (nicer headings, better multicolumn wrapping) and it made sense to keep that as part of this refactor. I could, of course, remove those changes if desired.

Diff Detail

Repository
rB Blender

Event Timeline

Was able to simplify the menu width estimation a bit.

This is essentially a roundabout way to get around one of the fundamental downsides with the way we draw the Blender UI. All our UI elements must always live inside the Blender windows because of the way we draw items using an OpenGL context.

In an ideal world, things like menus would be able to extend beyond the window borders, but since this is not terribly likely to be addressed, I think your workaround could be acceptable.

The estimation of menu width works well enough for this purpose, I think. LOL

But I could probably spend time to do it a bit better. I could actually blf_width() the longest strings in each column, rather than just using the number of characters. (n.b. UI_style_get(), uiFontStyle.widget.points) And then it is fairly known widths for icons and columns paddings. But didn't want to spend more time if the central idea (single column if not enough room) is not wanted.

Harley Acheson (harley) updated this revision to Diff 20508.EditedThu, Dec 26, 7:47 PM

Updated to current state of master.

Handles the odd case of the image file format list (which uses a category with name of " " to add a manual column break). I now treat this situation differently when forced to a single column.

And also changed the format a bit for collapsed categorized lists. I didn't like how the category name seemed attached more to the end of the prior list when in single-column. So in this patch they now look like following:

Improve estimation of menu width by measuring actual text width, rather than using number of characters.

Just use always one column (as it is done in all programs) it will solve many problems at once.
There are more problems and limitations with multi-column menus than advantages.

Small change to layout when in single-column mode, based on feedback (and mockup) from @marcus.pollio

While initially this seems nice enough, am not sure this change is a net gain.

This looks to further complicate some already fairly involved logic for menu drawing.

From what I can see this change is mainly useful the the language selector, the example of the space-type selector feels a bit contrived since I don't think it's common to use very narrow windows.

Very large menus like this already aren't all that useful... making it fit the window feels like it gives us an only slightly more usable interface, at the cost of code which becomes less maintainable.

Why not check on better ways to choose from large lists, such as:

  • Use a vertical list for the language selector (improve vertical list scrolling - if that's needed).
  • Use a searchable list as we use for ID selectors.
  • We could make enum popups scrollable/searchable if it exceeds a certain length.

@Campbell Barton (campbellbarton) - While initially this seems nice enough, am not sure this change is a net gain.

Yes, I was surprised how much complexity it adds just to do it fairly well.

the example of the space-type selector feels a bit contrived since I don't think it's common to use very narrow windows.

Surprisingly it wasn't contrived. That was specifically shown by someone who was "tearing off" existing editors, dragging to a separate monitor and then changing to something else. What he experienced could also be helped a bit if I just went back to simplifying the result of "New Window" (versus "New Main Window").

Why not check on better ways to choose from large lists, such as:

  • Use a vertical list for the language selector (improve vertical list scrolling - if that's needed).
  • Use a searchable list as we use for ID selectors.
  • We could make enum popups scrollable/searchable if it exceeds a certain length.

Yes, there is probably lots of ways of approaching this. Taking a break for a couple weeks and will play around when I get back.