Page MenuHome

Modal options are missing from 3D view header for many operators
Closed, ResolvedPublic

Description

Problem
Many operators have modal options available to the user but many of these are not displayed in any way and remain totally hidden. In many cases these options are only found accidentally or by reading the documentation (assuming it's up to date).

Solution
Add modal options to the 3D view header for each operator. The Knife tool can be used as a good example. The header should include option names, hotkeys, and status in the case of toggles (such as cut through: ON/OFF).

Event Timeline

IMO the settings that change the mode of the tool should go with the rest of the tool settings (cut through ON/OFF as a checkbox), so in the current Redo Panel, or maybe in the future in the Brechtbar - Because Blender should provide GUI elements to control these settings, as in the rest of the UI (the hotkeys can stay, for those who already memorized them).

I would leave all the info in the header though, along with the modifier keys that can be used with the tool ("Hold Ctrl to snap to edge midpoints." for example).

Brecht Van Lommel (brecht) triaged this task as Normal priority.Dec 6 2013, 2:25 PM

One of the problems with showing keys in headers is when keymaps are NOT hard-coded (which is generally a good thing!),

But means its not so simple to display the shortcuts in the header.

We could start by having an API to display keymaps in the header (along with some optional descriptive text for each key).

I'm happy to do this, fly/walk modes would be good examples to test this too.

An API to display keymaps would be idea. The benefits would go towards the existing tools and the many addons that could make use of it.

I don't think it's a good idea to use the header in the first place. Some modal ops hijack it and display a very long line of text with the hotkeys mixed more or less clearly into it.

Putting checkboxes etc. into the future Brechtbar would be a better solution, but still not solve the issue that it's a very vertical info/command "bar" (unless the Brechtbar will be a two row thing).

Here's a quick mockup of how it could look in a sidebar (based on Andrew Price's UI Proposal):

Here are some early reflexions on that topic. I would devide it in small, easy to do and integrate steps:

API to get shortcuts

That’s the simplest part (design-wise), imho we should have something like two funcs:

  • Get the representation of an hard-coded shortcut (giving keycodes and modifiers).
  • Get the representation of a (modal) keymap item (giving some 'context' data like current operator etc., have to check this more precisely).

Note for a start those funcs should probably just return a simple textual representation of shortcuts, but later we might want to play it fancy with nice widget-style for shortcuts. ;)

API to show help/info in header

Currently modal ops just store some text info into a header's string. Though very simple and efficient, I see two main issues with this approach:

  • It is ultimately very limited in possibilities (e.g. very hard to use fancy editfield-like widgets when using numinput, icons for some shortcuts like mousebuttons, which would even take less space than current codes, etc.).
  • Space is a real big issue. Right now, unless you have a full HD screen with 3DView taking most of it, you just do not see the whole fly/walk modes text, e.g.

So I would see new system like this:

  • A callback, which get a UILayout object and some flags.
  • Each op then layout its help/info message, based on given flags.
  • We could even add an 'auto help' helper for simple operators using modal keymaps, that would simply output all modal keymaps info.

Ultimately, I’d see two modes, one (displayed in header) being to draw actual states/values (and numinputs), the other to draw the full 'help'. I’d see e.g. the second one as a semi-transparent, text/icon-only (i.e. completely passive) popup shown when pressing a key, like F1. Here is a quick mockup:


We could also use the 'Operator' panel for that, but I like the idea less, because space is not extendable there, and because it means you'd have to open tools to see the help…

Actually, I think we may decide to reserve some keys common to all modal keymaps, e.g. the Fx ones, to be used by common features like 'show help', 'enable numinput', etc.?

So, another valid point from T41763 - values of events (press, release, click, double-click, etc.) are never reported in shortcuts feedback to user…

This is tricky to handle well imho, at least as long as we stick to pure text here. But valid thing to think about! ;)

Hey @Bastien Montagne (mont29), sorry for not replying to this earlier.

API for to get shortcuts

This bit is really important to solving the problem and seems pretty straight forward.

API to show info in header

This gets more difficult, though. The mockup you've shown uses what appears to be a floating panel, which we don't really support right now. Perhaps we could, but that's a separate, and significant discussion for another task.

For now, what about keeping it simple and building the API Shortcuts, which can then be used to pull in info to the header (like we are already doing, but without the header being hardcoded).

Related: modal keymap improvements

One of the issues I see with most of our modal operators, is that the keycaps are hard-coded, and are not changeable by the average user. It would be very advantageous if add-on devs could create modal keymaps just like they can regular keymaps. These modal keymaps could then be pulled into the header via the above proposed API.

Transform Modal Keymap - an example of what add-ons ought to be able to define for use within modals.

Actually, first part (API to get shortcuts) has a first 'proof of concept' patch in D780. ;)

Ah nice @Bastien Montagne (mont29). From a first pass that appears to be working :) If there's anything in particular you'd like me to look at just say so.

Think we can close this one, not all modal ops use the new stuff still, but no need to keep a design task open for that, will be addressed in near future anyway. ;)

Great @Bastien Montagne (mont29)!

Am I correct in thinking the new modal API stuff also works for Python add-ons to create a modal keymap?

Eeeh, not sure what you mean exactly? This new 'API' is very small change in the end, it just allows C code to get a human-readable representation of a keymap in a compact way.

If you mean, 'defining new modal handlers from py for a given modal operator', then I’m afraid this would be way beyond the scope of this change - would need a way to add and remove those modal handlers from py… Do not know that code enough to be sure off hands, but this sounds quite different topic (more related to the ultimate goal, to be able to define whole new editors from py…).