Modal options are missing from 3D view header for many operators #37699

New Issue

Jonathan Williamson · 2013-12-04T20:50:21+01:00

2013-12-04 20:50:21 +01:00

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

**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*). ![Screen_Shot_2013-12-04_at_1.48.23_PM.png](https://archive.blender.org/developer/F36444/Screen_Shot_2013-12-04_at_1.48.23_PM.png)

Jonathan Williamson commented

2013-12-04 20:50:21 +01:00

Changed status to: 'Open'

Jonathan Williamson commented

2013-12-04 20:50:21 +01:00

Added subscribers: @JonathanWilliamson, @ideasman42, @brecht, @mont29

blender-admin commented

2013-12-04 20:50:21 +01:00

#41763 was marked as duplicate of this issue

Paweł Łyczkowski commented

2013-12-05 13:11:51 +01:00

Added subscriber: @PawelLyczkowski-1

Paweł Łyczkowski commented

2013-12-05 13:11:51 +01:00

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

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

Simon Repp commented

2014-01-01 21:54:17 +01:00

Added subscriber: @simonrepp

Campbell Barton commented

2014-01-03 15:11:01 +01:00

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.

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.

Jonathan Williamson commented

2014-01-03 16:57:58 +01:00

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.

Campbell Barton self-assigned this 2014-01-04 01:26:08 +01:00

CodeManX commented

2014-01-05 22:37:49 +01:00

Added subscriber: @CodeManX

CodeManX commented

2014-01-05 22:37:49 +01:00

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

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): ![InfoBox-Mockup.png](https://archive.blender.org/developer/F62490/InfoBox-Mockup.png)

Campbell Barton was unassigned by Bastien Montagne

2014-08-31 14:18:03 +02:00

Bastien Montagne self-assigned this 2014-08-31 14:18:03 +02:00

marc dion commented

2014-08-31 14:48:48 +02:00

Added subscriber: @MarcClintDion

Bastien Montagne commented

2014-09-01 12:50:04 +02:00

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

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: ![modal_ops_help_info_mockup_01.png](https://archive.blender.org/developer/F107855/modal_ops_help_info_mockup_01.png) 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.?

Bastien Montagne commented

2014-09-09 22:58:08 +02:00

Added subscriber: @Cenda

Bastien Montagne commented

2014-09-09 22:58:08 +02:00

◀ Merged tasks: #41763.

Bastien Montagne commented

2014-09-09 22:59:49 +02:00

So, another valid point from #41763 - 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! ;)

So, another valid point from #41763 - 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! ;)

Jonathan Williamson commented

2014-10-14 16:36:30 +02:00

Hey @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).

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.

Hey @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*. ![Screen_Shot_2014-10-14_at_9.35.21_AM.png](https://archive.blender.org/developer/F116656/Screen_Shot_2014-10-14_at_9.35.21_AM.png)

Bastien Montagne commented

2014-10-15 09:36:38 +02:00

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

Actually, first part (API to get shortcuts) has a first 'proof of concept' patch in [D780](https://archive.blender.org/developer/D780). ;)

Jonathan Williamson commented

2014-10-16 18:37:57 +02:00

Ah nice @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.

Bastien Montagne commented

2015-07-12 22:21:21 +02:00

Changed status from 'Open' to: 'Resolved'

Bastien Montagne closed this issue

2015-07-12 22:21:21 +02:00

Bastien Montagne commented

2015-07-12 22:21:21 +02:00

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. ;)

Jonathan Williamson commented

2015-07-12 22:59:40 +02:00

Great @mont29!

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

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

Bastien Montagne commented

2015-07-13 00:12:56 +02:00

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…).

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…).

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Modal options are missing from 3D view header for many operators #37699

API to get shortcuts

API to show help/info in header

API for to get shortcuts

API to show info in header

Related: modal keymap improvements