WIP: UI: Refactor menus in Edit Mode #113122
No reviewers
Pablo Vazquez
Campbell Barton
Harley Acheson
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
5 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#113122
Loading…
Reference in New Issue
No description provided.
Delete Branch "JulienKaspar/blender:verb_mesh_menu"
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?
This is an experiment together with #113115.
Menu Layout
Shortcuts
The menu shortcuts
Ctrl V/E/Ffor the Vertex, Edge and Face menus are used often for specific operators.This is addressed in this PR by assigning menus with overlap in their use cases:
Ctrl V= Cut/SlideCtrl E= Write (Attributes)Ctrl F= Fill/ConnectCtrl VMenuCtrl EMenuCtrl FMenuAny additional needed operators should be available via the context menu (Improved with #113115) and quick favourites.
Many other menus also already have shortcuts.
Other Object Types
The mesh edit mode menus are setting the example. I reorganised the other object type menus to follow the same structure.
Issue with previous menus
The current organisation is messy and hard to understand.
The current menus are noun-oriented, which makes the organisation arbitrary. Many operators fit into multiple or all menus.
The current logic of the Vert/Edge/Face menus seems to be the selection requirement for the operator.
But some operators like
FillandGrid Fillgo against that logic by being in the Face menu. They should be in the Vertex menu underNew Edge/Face from Vertices. To the user this might seem wrong though.duplicates of some operators can also be found in the Mesh menu.
As a result, knowing in which menu any given operator is located, is a matter of memorizing, not understanding.
WIP: Verb oriented edit mode menusto Verb oriented edit mode menusVerb oriented edit mode menusto UI: Verb-oriented menus in Edit ModeUI: Verb-oriented menus in Edit Modeto UI: Refactor menus in Edit Mode7aa3f7ebedto0922e1d693Marking Seams previously:
Marking seams now:
Number of clicks needed is increased for such a basic task, which you need to do over and over and over when you're UV unwrapping.
Right-click menu also can remember last choice and put that option right at the mouse. That doesn't happen when operator is hidden in submenu.
UX work should happen with workflow in mind, not cleanliness.
@Nika-Kutsniashvili Sorry that this wasn't as clear. It would be
Ctrl E-> Mark Seam. The shortcut is for the "Write" menu.True, but it's impossible to add all most used Write menu items to the context menu. That's why the "Write" menu would be exposed with the shortcut
Ctrl Eright next to it.The context menu is in that case more a discoverability aid.
(EDIT: This is actually more related to #113115 instead of this PR)
UX is definitely the most important motivation behind this PR. So if there's any feedback it's always important to hear.
Thank you for clarifying. That is indeed better. Ctrl E shortcut should show on Write menu right? But I wonder if that's even necessary. There aren't that many items there, and might be better if they're directly exposed in Attribute menu. People who use menus directly instead of shortcuts will appreciate that more I think.
But I still think Seam options should be added in the context menu back. It is much easier to access and you can work with one hand essentially, and context menu should be filled with most used items in my opinion. There are many things currently in there that you don't need to recall very often, like Bisect, Smooth, Vertex Slide. And just because of how integral marking seams are they deserve place above those in my opinion. But if they're in Ctrl E menu I wouldn't mind it too much.
There will be more :)
The geo nodes team will eventually add more operators to write custom attributes.
That's a seperate PR. This one is just about the header menus. WOuld be good to have that discussion on #113115
3be1e0a264to2ea1c4d00d@blender-bot package
Package build started. Download here when ready.
@pablovazquez @Harley @ideasman42 This PR is now complete. I went ahead and added the same changes to curve, surface and gpencil object types so all edit mode menus are consistent.
Only one thing I'm not sure about yet:
@HooglyBoogly The Curve object type has the Tilt, Radius and Weight operators right now in the "Curve" menu. I'd like to put them all in an "Attribute" menu just like Mesh and Gpencil, but is that accurate? Because technically these are not attributes on this object type, right?
@blender-bot package
Package build started. Download here when ready.
I was asked by @JulienKaspar to have a look at this.
Removing vertex, edge and face menuI am a bit concerned about removing the vertex, edge and face menus and collect all of the respective operators in the mesh menu. This results in the mesh menu being very long and filled with operators. Trying to find operators in that long menu could cause mental overload and operators becomes hard top find for new users. I just want to give my POV on this. If you wtill want to go through with thisese changes I'm ok with it.
Moving the uv menuI feel quite concerned about removing this menu. I think it will be hard for new users to find the uv operators now that they are placed in
attributes > UV Mapping. It feels important that new users can easily find the operator sthat they are loooking for and I think that putting the uv menu as a child menu toAttributesTo counter this argument, as experienced, professional Blender user I still have no clue where to search for operator when I need one in edit mode. Its chaotic, everythings duplicated. For new users especially it will make more sense to have menus divided by type of operation instead of domain. When you want to bevel something you look for Bevel menu and look at your options. You dont have to go through domain menus and search where bevel might be. Its also unrelated to domain selection. I can be in Face select mode and use vertex bevel from vertex menu.
To avoid it being long we can split current one in for example Transform, Edit, Modify menus or something similar, buts its better in any form than duplicated domain menus
Its also great opportunity for addons and node tools to add operators in existing menus where people would expect to find them. For example I have Unbevel operator that I would put in Bevel menu, I have camera subdivision operator that I would put in Suvdivision menu and etc. Currently everyone is adding them at the end of domain menus and theres never any order to them, you jusr have to remember.
As for UV menus, I think its benefitial if new users are introduced to the concept of attribures early on and learn that seams are attributes. It makes sense for where Blender is headed.
...
EDIT: Moving my comment to Blender Chat in the #modeling-module channel. It's maybe better to start a discussion there.
Not entirely sure if a problem this PR is supposed to solve exists in practice.
Since the selection in Blender is convertible (vertices selection forms edges and faces selection), current menues allow to act in the desired context, this is why they are organized per domain.
If user want to bevel edges or verices the corresponding menu is used. The mindset is also simple - if user need to operate on faces it is always known where to look for available operations, which provides low entry threshold.
@1D_Inc I wish I could agree. But the menus are inconsistently organised by minimum needed selection rather than by a strict domain.
Like you said, it's the advantage that Blender is automatically converting the selection and rather agnostic about it.
There are many examples where you have to look in the wrong menu by the mindset you mentioned:
Or the menu item is in none of the 3 menus at all. You have to look in the generic Mesh menu for common operations like:
Because these can't easily be categorized into a strict domain type.
I like the Deform, Generate & Edit menus that were proposed in the module channel.
And to indicate that the minimum needed domain and amount is selected, the operators can be greyed out if not usable.
I'll see if I can invest some time in that approach soon.
Technically
Yes, and it is correct because it basically rips vertices but in the context of an edge (mode) selection.
It can also rip single vertices in context of a mouse cursor location (which allow to define ripped side, since edge context, which have predefined side, is not set in that case).
It also doesnot work with faces selection (which is rather annoying than useful)
Yes, because the operator basically subdivide edges selection (and doesnot subdivide ngon faces for example).
In Blender faces selection is a local case of edges selection, where the selected face is a face with all the surrounding edges being selected.
Face subdivision in Blender is a product of its edges subdivision.
Before/after:
Extrude has its own Alt+E menu, has no idea why it is placed in vertices, but it also basically extrude vertices (including the possibility of a context of edge or faces selection which defines corresponding selection filter if the corresponding mode is set).
Those contexts are the cost of a mesh engine flexibility. Any flexibility is powerful at providing exceptional abilities, but it always comes with its own price (most often at the price of increased handling/structural complexity)
That depicts that these operations do not have strict domain type and its contexts, conditions or limitations dependencies, effectively separating them from those that do.
At the system design level what this PR propose is transposing domain-function menu matrix in function-domain form.
Function-domain form assumes that there are no heavily domain-specific functions and domain context is less important, which is applicable for different software, but for Blender mesh modeling approach and structure it is far away from being truthful since domain-specific context and its separation are important in this approach due to higher mesh structural flexibility than in the other apps.
Preserving domain-context dependent operators clarity was the main obstacle we faced those years when we tried to design the same transpose, so I mentioned some of them.
I agree that Blender is very mixed in how the operators work. And there will always be "domain-specific" operators around. It's usually even in their name.
But often the way Blender is used and a lot of shortcuts work, is by being "function-specific". The domain is implied and predefined by the selection or switched during the modal operation.
So this PR is trying to make this more obvious. The vert/edge/face selection modes and menus are not important for the operations themselves.
Each system has an imprint of how it was originally created (for example, both mercedes and daimler created the very first car almost simultaneoulsly, but mercedes started from bicycles, so it created 3-wheels car, and daimler started from trains, so its car had 4 wheels) , so I have an assumption which looked convincing.
In the most mesh modeling software mesh engine has been created from operators demands - programmers there took all the operators that has been known at the time, like extrude, bevel and so one, and designed mesh engine that satisfies all of them (for example, IFC file format was created on the Autodesk conference where lots of manufacturing software companies tried to unifiy all those operators between different software)
This way operators-oriented mesh has been obtained.
Blender went the opposite way.
It has taken ready-made Wavefront OBJ-like mesh specification, which is naturally much more flexible than standard mesh realizations obtained from operator demands, and then designed modeling operations that could possibly satisfy its demands and requirements from scratch (this is why Blender mesh has such a tight OBJ format features support).
This way mesh-oriented operators has been obtained.
This is just an assumption and I never tried to confirm it, but it fits different software observations quite well.
If you see such a possibility, you can try transposing then, it's a good system design experience, maybe you'll have better luck than us.
I'm putting this on hold for a bit. I won't have much time to work on this soon.
Overall I think this implementation needs more buy-in and stakeholders from users before going forward. Many still rely on the vert/edge/face menus, even if out of habit.
There was also the idea to split the "Mesh" menu up into verb-specific menus to avoid an overly long menu that hurts discoverability. This still needs to be tested for feedback.
UI: Refactor menus in Edit Modeto WIP: UI: Refactor menus in Edit ModeAs far as I remember, the main challenge was not to design menus themselves, but make them feel natural - like correspond to the way operators actually works.
For example, same correspondance issue could be found in maya, where users massively confuse origin system with pivot system, because the origin was intentionally hidden from user, or max where users are confused about instances (linked data objects) structure, since mesh data were also made hidden, and therefore disguising (so instances there feels more like magic when you learn a program without proper understanding that instances are objects that share the same mesh)
when we tried to rework the menu we ended up with a system that didn't have enough clarity about how the operators actually work, which was quite a disguise, especially in the beginning.
Such a menus became clear after understanding mesh mode - context operators relationship, and since some operators in some cases doesnot require contextual menus and supposed to be used mostly as a hotkeys, we didnt succeed to reach a breakthrough solution in this area to propose)
We also has got menues with bigger nesting, which wasnt very pleasant effect in terms of intensive using. Or maybe we made something wrong.
Checkout
From your project repository, check out a new branch and test the changes.