No way to distinguish enum buttons that support shift-click to select multiple #57690
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#57690
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?
Blender has some buttons that allow shift-click to select multiple, but no way to show the difference. eg:
Transform Tool, Gizmo's (Move / Rotate / Scale)
Added subscriber: @ideasman42
Added subscriber: @WilliamReynish
I wonder how best to solve this. We only use these types of radio-button widgets that allow multiple selections in a few places, but it's important to communicate that you can hold shift to pick more than one.
My first thought was to just turn them into separate checkbox toggles, but that doesn't work because at least one of them has to be selected always.
Maybe the theme could simply be more different for these types of toggles, but that's still not very clear.
Added subscriber: @CharlieJolly
@WilliamReynish What about a custom cursor for these cases?
@CharlieJolly: how do you mean?
@WilliamReynish Rather than the normal pointer you could use a pointer with a plus sign?
Added subscriber: @DuarteRamos
Maybe some sort of highlight hover effects encompassing all draggable properties/buttons.
The Highlight Label option may not work everywhere and be easy to miss, but may be replaced with a vertical line along all buttons
Please excuse the crude mockups, the hover effect could simply be just an outline around the buttons/properties, changing color or weight of text, or a simple vertical line across affected options.
Added subscriber: @brecht
@DuarteRamos, this task is about enum buttons like the move / rotate / scale settings in the transform tool, number buttons and checkbox/toggle buttons are different.
The hint to press Shift to select multiple could show in the tooltip at least, not sure how else a user would learn about this without docs or tutorials.
The plus icon appearing next to the cursor would make sense when Shift is pressed, not really before, but at that point it seems too late.
Added subscriber: @Harley
Probably not an acceptable answer, but...one thought is to not (somehow) highlight hidden behavior, but remove the hidden behavior...
So if you click on an unselected item it becomes selected without deselecting anything else. Click on a selected item and it becomes unselected, unless it is the only item selected.
This way users would know how to select multiples from the first moment they select anything. For users who complain about any added clicks, just make ctrl-clicking operate in the old exclusive behavior.
Again, just a (unpopular) thought. LOL
Another, less extreme idea, that does not require any behavior changes.
Use the rules and dividers between items to indicate visually how they are related logically.
So, for example, if multiple buttons are completely distinct from each other, then underscore that separateness by having a rule between them. But if they are related in a way - either more than one can be selected at a time - underscore the connectedness by removing rules between them, making them just parts of a larger group.
In the image below, Transform Orientations look as they do now because each selection is distinct. But Snapping options have their borders removed. Snapping Target are four distinct items, but Affect are multiple.
Similarly Transform Gizmo options lose their separations, as do the edit mode component selection icons:
Its another thought anyway...
@Harley These ideas seem very good to me. I actually agree with both of your ideas, which are not mutually exclusive.
Both would help to solve this problem.
To be honest, I don't think the first solution could be implemented in practice because the howls of protest would be unbearable. LOL. But it could be thought through. I had suggested using ctrl-click for current behavior, but that was wrong. That suggestion was really about just swapping the default behavior with the current Shift behavior. And we do have some (fairly) consistent rules on how shift, ctrl, and alt change selection behaviors.
The second suggestion does work quite well for lists, as shown in Transform and Snapping. Although while staring at that capture I realize that the title "Transform Orientations" shown should instead be a singular "Transform Orientation". Similarly, the "Snapping" title should be a plural "Snapping Elements".
@Harley I don't see why that would be an issue. To me it seems like a fine solution to make it add to the selection by default. It makes it immediately obvious that you can select multiple items. We don't use this widget type many places - I think that would ok, a nice improvement even.
I would happily aprove of this change. It would single handedly solve the problem by making it immediately discoverable, at the (IMHO small) expense of a little a little getting used to the new behavior.
Well ignoring any political aspects to it (just don't mention my name. LOL), the parts to be thought through carefully are mostly about "extending" selection while changing modes.
It is a very well-hidden feature, but not one we'd want to break. For any readers not familiar: if I am in vertex-select mode with only one vertex selected, and then change to edge-select mode I will then have nothing selected. But if I change selection modes while holding ctrl key then that single selected vertex could turn into multiple selected edges or faces.
Right now this feature works well when changing from a singular mode to another singular mode. But the feature is currently broken for multiple mode selection.
So what I mean is that if you start with my earlier single-vertex selection while in vertex select mode, holding shift AND ctrl to add vertex-select mode does NOT extend selection, even though it probably should. So that would mean it would similarly be broken if the behavior of selecting versus shift-selecting were swapped. As you add the higher mode, if ctrl is pressed then do the extension to the higher mode. But then again, there could be other technical reasons why extension does not already work like this.
Added subscriber: @ThinkingPolygons
I guess I'm the only one who thinks this is not an issue.
A tooltip would be more than enough. I mean, there are plenty of apps with similar feature and yet there's nothing fancy happening with their buttons.
No, I am just cursed with overthinking everything I ever think about. LOL. AFAICT if we fix multi-mode selection extension then we could just swap selection with shift-selection.
Added subscriber: @jenkm
At this point, it's all mixed up.
o_O
Move/Rotate/Scale in the transform tool must work like Move/Rotate/Scale in the snapping, no Shift is required. This is the most obvious way, that does not require additional explanations. And it's not called radio buttons.
Shading is radio buttons. I see no reason to separate them visually from the previous ones because you can't miss some feature or do something wrong. You just clicking and everything is obvious.
Selection Modes buttons, it can be a special widget looking different, (perhaps even here you can add a small arrow with a drop-down menu containing expands/contrast switching options). Or just, it can work like all the rest, without Shift key for multiple selection.
And yet, no one will read the tooltips to learn how the buttons work, I assume that many users do not know that, for example, the "Snapping To" options can be multiple at the same time.
@jenkm
Yes, this seems to be the most straight-forward solution, although it does change the interaction a bit. I at least would be fine with this change.