Modal options are missing from 3D view header for many operators #37699
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
8 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#37699
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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).
Changed status to: 'Open'
Added subscribers: @JonathanWilliamson, @ideasman42, @brecht, @mont29
#41763 was marked as duplicate of this issue
Added subscriber: @PawelLyczkowski-1
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).
Added subscriber: @simonrepp
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.
Added subscriber: @CodeManX
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):
Added subscriber: @MarcClintDion
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:
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:
So I would see new system like this:
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.?
Added subscriber: @Cenda
◀ Merged tasks: #41763.
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! ;)
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.
Actually, first part (API to get shortcuts) has a first 'proof of concept' patch in D780. ;)
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.
Changed status from 'Open' to: 'Resolved'
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 @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…).