WIP: UI: Refactor menus in Edit Mode #113122

Draft
Julien Kaspar wants to merge 7 commits from JulienKaspar/blender:verb_mesh_menu into main

When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.
Member

This is an experiment together with #113115.

Menu Layout

  • Merge the Vertex, Edge and Face menus into the Mesh menu
  • Verb-oriented menus (Organise the operators around what users want to do, instead of the input/output selection types)

context_current.png

Shortcuts

The menu shortcuts Ctrl V/E/F for 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/Slide
  • Ctrl E = Write (Attributes)
  • Ctrl F = Fill/Connect
Ctrl V Menu Ctrl E Menu Ctrl F Menu
context_current.png context_current.png context_current.png

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

Gpencil Gpencil Attributes Curve Surface
gpencil_menu gpencil_attributes curve_menu surface_menu

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 Fill and Grid Fill go against that logic by being in the Face menu. They should be in the Vertex menu under New 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.

This is an experiment together with #113115. # Menu Layout - Merge the Vertex, Edge and Face menus into the Mesh menu - Verb-oriented menus (Organise the operators around what users want to do, instead of the input/output selection types) ![context_current.png](/attachments/aa279cf3-af5a-40be-ac74-db62a66f912e) # Shortcuts The menu shortcuts `Ctrl V/E/F` for 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/Slide - `Ctrl E` = Write (Attributes) - `Ctrl F` = Fill/Connect | `Ctrl V` Menu | `Ctrl E` Menu | `Ctrl F` Menu | | -------- | -------- | -------- | | ![context_current.png](/attachments/fd3a19cb-2482-435d-b296-291279a9e3a2) | ![context_current.png](/attachments/8faf74bb-f56d-4f70-a29b-f65d2d6f8ce9) | ![context_current.png](/attachments/fd62c213-85e9-4495-a098-e863ca79b2eb) | Any 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. | Gpencil | Gpencil Attributes | Curve | Surface | | -------- | -------- | -------- | -------- | | ![gpencil_menu](/attachments/803a6680-144e-48c8-8b9c-6ea52f2fe100) | ![gpencil_attributes](/attachments/b2bd7e21-4bcc-4f2e-b41f-f0a76cac9343) | ![curve_menu](/attachments/abe65c67-9241-49b0-8aa6-0d09c725aa49) | ![surface_menu](/attachments/f520d208-32ea-4fec-9f4e-cccd4a580244) | # 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 `Fill` and `Grid Fill` go against that logic by being in the Face menu. They should be in the Vertex menu under `New 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.
Julien Kaspar changed title from WIP: Verb oriented edit mode menus to Verb oriented edit mode menus 2023-10-04 15:46:56 +02:00
Julien Kaspar added the
Module
User Interface
Interest
Modeling
labels 2023-10-04 15:47:10 +02:00
Julien Kaspar requested review from Pablo Vazquez 2023-10-04 15:47:18 +02:00
Julien Kaspar requested review from Campbell Barton 2023-10-04 15:47:30 +02:00
Julien Kaspar requested review from Harley Acheson 2023-10-04 15:47:39 +02:00
Pablo Vazquez changed title from Verb oriented edit mode menus to UI: Verb-oriented menus in Edit Mode 2023-10-08 18:17:08 +02:00
Pablo Vazquez added this to the User Interface project 2023-10-08 18:17:18 +02:00
Julien Kaspar changed title from UI: Verb-oriented menus in Edit Mode to UI: Refactor menus in Edit Mode 2023-10-10 14:43:50 +02:00
Julien Kaspar force-pushed verb_mesh_menu from 7aa3f7ebed to 0922e1d693 2023-10-11 15:19:30 +02:00 Compare
Contributor

Marking Seams previously:

  • Right-Click > Mark Seam

Marking seams now:

  • Ctrl + E > Move mouse to Write menu > Mark Seam

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.

Marking Seams previously: - Right-Click > Mark Seam Marking seams now: - Ctrl + E > Move mouse to Write menu > Mark Seam 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.
Author
Member

@Nika-Kutsniashvili Sorry that this wasn't as clear. It would be
Ctrl E -> Mark Seam. The shortcut is for the "Write" menu.

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.

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 E right 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.

@Nika-Kutsniashvili Sorry that this wasn't as clear. It would be `Ctrl E` -> Mark Seam. The shortcut is for the "Write" menu. > 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. 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 E` right 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.
Contributor

@Nika-Kutsniashvili Sorry that this wasn't as clear. It would be
Ctrl E -> Mark Seam. The shortcut is for the "Write" menu.

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.

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 E right next to it.
The context menu is in that case more a discoverability aid.

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.

> @Nika-Kutsniashvili Sorry that this wasn't as clear. It would be > `Ctrl E` -> Mark Seam. The shortcut is for the "Write" menu. > > > 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. > > 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 E` right next to it. > The context menu is in that case more a discoverability aid. > > 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.
Author
Member

There aren't that many items there, and might be better if they're directly exposed in Attribute menu

There will be more :)
The geo nodes team will eventually add more operators to write custom attributes.

But I still think Seam options should be added in the context menu back.

That's a seperate PR. This one is just about the header menus. WOuld be good to have that discussion on #113115

> There aren't that many items there, and might be better if they're directly exposed in Attribute menu There will be more :) The geo nodes team will eventually add more operators to write custom attributes. > But I still think Seam options should be added in the context menu back. That's a seperate PR. This one is just about the header menus. WOuld be good to have that discussion on #113115
Julien Kaspar force-pushed verb_mesh_menu from 3be1e0a264 to 2ea1c4d00d 2024-01-17 11:47:04 +01:00 Compare
Julien Kaspar added 1 commit 2024-01-17 11:49:23 +01:00
Added separator
Some checks failed
buildbot/vexp-code-patch-lint Build done.
buildbot/vexp-code-patch-darwin-arm64 Build done.
buildbot/vexp-code-patch-darwin-x86_64 Build done.
buildbot/vexp-code-patch-linux-x86_64 Build done.
buildbot/vexp-code-patch-windows-amd64 Build done.
buildbot/vexp-code-patch-coordinator Build done.
2c4cb1e107
Author
Member

@blender-bot package

@blender-bot package
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR113122) when ready.
Julien Kaspar added 1 commit 2024-01-17 14:58:13 +01:00
Added comments and more object types.
Some checks failed
buildbot/vexp-code-patch-lint Build done.
buildbot/vexp-code-patch-darwin-x86_64 Build done.
buildbot/vexp-code-patch-darwin-arm64 Build done.
buildbot/vexp-code-patch-linux-x86_64 Build done.
buildbot/vexp-code-patch-windows-amd64 Build done.
buildbot/vexp-code-patch-coordinator Build done.
e5a9f2ebe6
Added same changes for curve, surface and gpencil object types. Menu sections are now commented for clarity.
Author
Member

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

@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?
Author
Member

@blender-bot package

@blender-bot package
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR113122) when ready.
Member

I was asked by @JulienKaspar to have a look at this.

Removing vertex, edge and face menu
I 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 menu
I 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 to Attributes

I was asked by @JulienKaspar to have a look at this. `Removing vertex, edge and face menu` I 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 menu` I 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 to `Attributes`
Contributor

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

To 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.
Author
Member

...

EDIT: Moving my comment to Blender Chat in the #modeling-module channel. It's maybe better to start a discussion there.

... EDIT: Moving my comment to Blender Chat in the #modeling-module channel. It's maybe better to start a discussion there.
First-time contributor

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.

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.
Author
Member

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:

  • Extruding selected Faces/Edges to cursor = Vertex -> Extrude to Cursor or Add
  • Rip selected Edge Loop = Vertex -> Rip Vertices
  • Subdivide selected Faces = Edge -> Subdivide

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:

  • Duplicate
  • Mirror
  • Extrude (The most often used one)
  • Merge
  • Split
  • Knife
  • Symmetrize

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.

> 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: - Extruding selected **Faces**/**Edges** to cursor = **Vertex** -> Extrude to Cursor or Add - Rip selected **Edge** Loop = **Vertex** -> Rip Vertices - Subdivide selected **Faces** = **Edge** -> Subdivide 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: - Duplicate - Mirror - Extrude (The most often used one) - Merge - Split - Knife - Symmetrize 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.
First-time contributor

Technically

There are many examples where you have to look in the wrong menu by the mindset you mentioned:

  • Rip selected Edge Loop = Vertex -> Rip Vertices

Yes, and it is correct because it basically rips vertices but in the context of an edge (mode) selection.

image

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

image

It also doesnot work with faces selection (which is rather annoying than useful)

image

  • Subdivide selected Faces = Edge -> Subdivide

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:

image

  • Extruding selected Faces/Edges to cursor = Vertex -> Extrude to Cursor or Add

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

image

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)

Technically > There are many examples where you have to look in the wrong menu by the mindset you mentioned: > - Rip selected **Edge** Loop = **Vertex** -> Rip Vertices Yes, and it is correct because it basically rips vertices but **in the context** of an edge (mode) selection. ![image](/attachments/02782725-6093-4b6b-a85f-4612f9029d28) 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). ![image](/attachments/6bf15120-d806-4fbe-ab8a-63876c57da7d) It also doesnot work with faces selection (which is rather annoying than useful) ![image](/attachments/c153a7f2-fb10-402d-af8e-bdfa2045c4f4) > - Subdivide selected **Faces** = **Edge** -> Subdivide 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: ![image](/attachments/798db9ef-d3e0-48f7-a093-d160544f5f34) > - Extruding selected **Faces**/**Edges** to cursor = **Vertex** -> Extrude to Cursor or Add 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). ![image](/attachments/db7e306a-dc12-4a62-951b-12f536ad4da3) 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)
First-time contributor

Because these can't easily be categorized into a strict domain type.

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.

> Because these can't easily be categorized into a strict domain type. 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.
First-time contributor

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.

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.
Author
Member

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.

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.
First-time contributor

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.

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.
First-time contributor

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.

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.

> > 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. 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.
Author
Member

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

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. ![image](/attachments/d9fb1f67-c128-4a17-a662-9cab7ace4f7a)
Julien Kaspar changed title from UI: Refactor menus in Edit Mode to WIP: UI: Refactor menus in Edit Mode 2024-02-16 12:34:48 +01:00
First-time contributor

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

As 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.
Some checks failed
buildbot/vexp-code-patch-lint Build done.
buildbot/vexp-code-patch-darwin-x86_64 Build done.
buildbot/vexp-code-patch-darwin-arm64 Build done.
buildbot/vexp-code-patch-linux-x86_64 Build done.
buildbot/vexp-code-patch-windows-amd64 Build done.
buildbot/vexp-code-patch-coordinator Build done.
This pull request has changes conflicting with the target branch.
  • scripts/startup/bl_ui/space_view3d.py

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u verb_mesh_menu:JulienKaspar-verb_mesh_menu
git checkout JulienKaspar-verb_mesh_menu
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Code Documentation
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
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
Viewport & EEVEE
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
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
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
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Severity
High
Severity
Low
Severity
Normal
Severity
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
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#113122
No description provided.