Page MenuHome

Menu Editor for Quick Favorites
Confirmed, NormalPublicTO DO

Tokens
"Love" token, awarded by franMarz."Love" token, awarded by Shimoon."Love" token, awarded by Tetone."Love" token, awarded by duarteframos."Love" token, awarded by xrg."Love" token, awarded by billreynish.
Assigned To
None
Authored By

Description

Currently users can only manage menu items in the quick-favorites menu by adding/removing items.

This task proposes to:

  • Create a generic menu editor in the user preferences.
    • Add/remove menu items
    • Re-ordering menu items.
    • Operators options should be able to be changed or unset - as we have with the keymap editor.
Implementation
  • This could share UI code with the keymap editor for adjusting operator settings, since internally they are very similar.
  • We may support multiple kinds of menus, besides "Quick Favorites", internally there is support for this. Even if this isn't exposed to users initially.

    This would be useful for declaring user defined toolbars for example.
User Interface

Here's how the UI could be organized:

Event Timeline

Campbell Barton (campbellbarton) changed the task status from Needs Triage to Confirmed.Jan 17 2020, 10:08 AM
Campbell Barton (campbellbarton) updated the task description. (Show Details)
Campbell Barton (campbellbarton) changed the subtype of this task from "Report" to "To Do".Jan 17 2020, 10:12 AM

Here's a fairly quick mockup to show the concept:

@William Reynish (billreynish) looks good, prefer this to the keymap style UI which I find tends towards too much scrolling, getting slow at times too.

This layout makes better use of available space:

Did you consider making it more like the keymap editor layout? Where you have a list of boxes that you can expand for the options.

Not saying that we should take the keymap editor as example of good design, but I think its layout is generally okay.
Otherwise it does feel a bit inconsistent, so I'm just wondering if it was considered.

@Julian Eisel (Severin) That was the first thing I did in fact :)

But Campbell pointed out that it probably makes it harder to navigate, and seeing multiple lists at once isn't likely to be that useful. Some ops have *many* options, which would mean lots and lots of scrolling, and lots of opening and closing panels.

Here's the first mockup:

However, your point stands that it is a bit inconsistent. One solution of course is to make the keymap editor also work more like this.

One solution of course is to make the keymap editor also work more like this.

I vote it
The only drawback I see is when comparing options.
If not all of the preference editors were synchronized, it would be resolved, they are currently a clone.

One solution of course is to make the keymap editor also work more like this.

I vote it
The only drawback I see is when comparing options.
If not all of the preference editors were synchronized, it would be resolved, they are currently a clone.

The keymap editor needs work, although the design hasn't yet been done as far as I know (details should be added to T68884: Keymap system refactor eventually).