The Context Menu that pops up when you right-click in the 3D Viewport is not a context menu.
It certainly looks like one, but is not. You can right-click on things and a menu will pop up that contains specialized items. But the included items only depend on what objects were already selected and active before the menu was invoked. It will be the same regardless of where you click, so the entire menu could just as well be hanging from the header instead.
Technically, my experiments with this involve the following: adding an âob_cursorâ member to the View3D struct, giving âWM_OT_call_menuâ an invoke that sets the ob_cursor pointer based on ED_view3d_give_object_under_cursor(), and then extending ed_screen_context() so that I can get to this new âbpy.context.cursor_objectâ from python. Itâs enough to play with. I have no idea where ob_cursor is better stored, and Iâd imagine making a specific âWM_OT_call_3dv_contextmenuâ operator if I wasnât so lazy.
What can be done with this that you canât do otherwise? Well this means you could act on any object, not just the active one that had already been made active before you even clicked.
So you could have one mesh object selected, but then right-click on another and âadd to selectionâ. Right-click on any of them to âmake activeâ. You could then right-click on one of your cameras to make it the active one, without having to select it first. You could put an object into edit mode, then right-click another to âedit as wellâ.
Right now imagine selecting multiple mesh objects. You can right-click and select âparentâ but it doesnât matter where you clicked, the parent will be the âactiveâ object, probably the last you selected. With this change you could have three mesh objects selected, then right-click on an entirely different unselected object and âmake parentâ. It would be so much more intuitive.
So I am wondering if this is interesting at all to anyone? Is this a direction we were already planning on going? I have a feeling I am just jumping the gun on a known âto doâ, but also donât want to miss this by not pointing out the current shortcomings. Or it is also possible that I am thinking about this in entirely the wrong way. Regardless, Iâm not the right person to actually implement this properly as Iâm a blender source newbie and am terrible with python as well. LOL
I tend to agree here. Context means âDepends where you clickâ. If itâs on a light, itâs different, if itâs on an empty space, different, if itâs on the veritice, different. It should not have to be Lclick then Rclick to change the context.
The same should be true in other editors. Right click without selecting a keyframe should bring up itâs context menu, on the timeline different, on the panels different, in the properties different, etc.
It should be consistent throughout the UI, so I agree with you. Iâm curious about how you would code it, as I had no idea you could detect where the mouse click was other than in the 3D viewport or UI elements.
In fact, the Rclick context menuâs are so⌠odd, that when you drag the timeline in Lclick select maps you canât even get to that menu! You drag the timeline instead.
In the Bforartists 2.8 fork, they removed the context menus entirely mainly due to being header menu double entries and not really contextual at all. They would love to have a true contextual system, maybe even a contextual pie menu on one click - but till then⌠not sure how to do it.
Right now the context menus are launched in a very simple way. The keymap calls an operator called WM_OT_call_menu that launches a menu in python with a name supplied to that operator. So if you are in object mode it calls âVIEW3D_MT_object_context_menuâ, but if you are in edit mode and the active object is a mesh it calls âVIEW3D_MT_edit_mesh_context_menuâ, etc.
How I think it should work is that only ONE python menu should be called regardless of mode or what is selected or active and it should know what thing was under your mouse at the time. That way it can do a lot more branching for different conditions. Like right-clicking on a mesh object that is not being edited while in edit mode so that you can edit that one as well.
My experiments with it involve adding a new member to the View3D struct to hold the âcursor objectâ. Then changes to the ed_screen_context() function so that python scripts can see that object as âbpy.context.cursor_objectâ.
Then I made a new operator in view3d_ops that finds the object under the mouse, using ED_view3d_give_object_under_cursor(), adds that object to the current View3D before calling a python menu. So it then knows what object you clicked on, if any.
That is actually enough for this to work. Python scripts already know what mode you are in, what is selected, what is active, etc. This just adds this one new object. Iâm am just not that used to Python, so I would not be the best person to flesh the idea out.
My current struggle is how to also allow context menus on the navigation widgets (top-right icons for ortho/persp, etc). I would love to see options on them. It would be worth it just for âauto perspectiveâ.
Hi! While this proposal makes total sense for left click selection, Iâm wondering how this should be managed for right click selection instead.
At the moment the âcontext menuâ is called with W, and I think it would be really strange to have a key shortcut performing different things depending on the mouse position, while any other one is selection based.
Another thing that comes to my mind is that something like this would probably need to be paired with some sort of âselection predictionâ on mouse over (I donât know if this term is correct), otherwise I think it would be quite difficult to use it in complex scenes with a lot of objects.
Selection pre-highlight is still years behind in Blender and⌠for another topic of debate, but yes, it would be necessary to make it work nicely (though Iâve used this workflow in many software without it). Rclick select does make a contextual menu typical of most Lclick select workflows in mostly all software somewhat odd if it was all in Rclick select, maybe as a double click?.. but that is Blender. Indeed rightclick contextual menu is indeed mainly for Lclick select workflows.
Of course!. With your message I now realize why this is working as it is: Devs working with right-click select and that keymap not having any free mouse key bindings. So doing this âproperlyâ, as I see it, would not be a consideration at all.
I canât see how these things can coexist well. The best we could get is having context menus that differ radically between right- and left- click and I doubt that would be acceptable. Although the current state seems pretty dim in that it the âWâ just brings up menus that are pretty-much identical to the menus on the header.
Yes that would be nice. Although that does seem unlikely to get. I have not played with anything too complex yet though, although surprised that cameras and lamps are easy to select this way.
Currently looking at object iterators. Most operators operate on âselected_editable_objectsâ and so this requires something a bit different. Basically we want to operate on only the mouse object if is not selected, but all selected objects if it is.
Changing the contents depending on where you click vs what you have selected is a different way to do it, but be aware that it can cause some problematic issues in common cases:
When you want a context menu to act on multiple selections
Some elements might be hard to reliably hit, like vertices or simply small objects, or objects that are hidden behind others
To be fair, doing it this way is the correct, and only, way to do it for âContext Menus.â I canât think of any other programs doing it any other way. The current are just dropdown menus that happen to appear near the mouse - they may as well be on the header (and they are already there too).
Imagine having two lamps and two cubes, with the cubes selected (one active naturally).
Right-clicking on a lamp would just act on that one lamp. Right-click on a cube though and the menu could act on both (since the mouse object was selected) for most operations. But you could still include active-specific options. So âmake activeâ on the non-active selected object for example. But we could also include âmake activeâ on a non-selected object by just having that action add to selection and also make active.
For sure, but no harder than they are to select initially. But yes, there are lots of weeds there. It is very possible that doing this properly is just not practical without pre-selection highlighting.
For overlapping objects we might be able to do something like that menu you can get with alt-left click when there are overlapping objects.
But in edit mode it could act much the same as it is now. Still operate on the selected and active vertices, edges, and faces. The only difference being that when you right-click to initiate the context menu you must do so somewhere within the bounds of the object. But not a tough thing to do.
But imagine being in edit mode on one object, then just right-click on some other object to âedit as wellâ. I think we can only do this currently by shift-clicking on the (other objectâs) mesh icon in the Outliner. So a nicer way of dealing with this.
Looks like the weeds with this experiment are the sheer number of operators that will work on only the active object, not an arbitrary object. The ones that work on multiple objects wouldnât be too bad, but it is all the active-only ones that would be tough. So far I canât find any easy way of getting around thatâŚ
You would have to run a cycle to apply the same operator to the selection, as the default IMO.
The âActive Onlyâ workflow is so slow in Blender⌠that might be a worth project before going on context menuâs, make most of the UI default on âApply to Selectedâ instead of only Active. Would there be a way to check the context if itâs with a selection then pretend to âALTâ change the system, like apply to all selected?
#1 it seems obvious blender should have the python hooks to mke experiments like this POSSIBLE, regardlesss of what we do with the right-click/W menu right now. Otherwise, how can we even experiment?
#2 i think highlighting the context object after the right-click/W but before the context menu is drawn is sufficient. We donât need constant pre-selection highlighting
#3 an experimental context menu could be a hybrid of the current menu (which is not context sensitive) and a few âcontext object actionsâ at the top⌠in this way it doesnât break any behavior, it just gives us a way to experiment with adding a few context actions
I personally think this is a great direction to explore to make blender more accessible to users of other programs, and to fight shortcut bloat.
For example, a parenting workflow, where one selects some objects and then right clicks (or presses W) on the desired parent (whether it is selected or not) and sees it (temporarily) highlighted as context, with âcontext objectâ > âmake parentâ action at the top of the menu. Seems great, and doesnât change any existing blenderisms.
And if we can make a good enough set of context sensitive actions, perhaps someday the current non-context menu items be pushed into a right-click submenu.
That is a good point I think. I didnât think that it might be useful on its own to know the 3dview object (if there is one) under the mouse in python at the time the menu is invoked. I canât see it doing any harm to having that information. Except maybe the disappointment of not being able to do much with that object.
It might need a bit of a think. It is only the object in the current 3dview that was under the mouse at the moment you invoked the menu, and doesnât remain pointing at other objects as you move your mouse later. So I need to think about the naming of the thing.
@Harleya, my man, I would love you if you got something like this committed into master. Especially for use cases like this:
âŚYou could put an object into edit mode, then right-click another to âedit as wellâ.
âŚthen right-click on an entirely different unselected object and âmake parentâ.
âŚYou could then right-click on one of your cameras to make it the active one, without having to select it first.
âŚyou could act on any object, not just the active one that had already been made active before you even clicked.
Sir, this is absolutely the right way to be thinking of how a context menu should function. It should be contextual to the thing under the cursor.
I think jeskeâs point #1 is reason enough to at least expose this in the API, even if it isnât immediately used by Blenderâs native context menus.
As I spend more time working with Blenderâs python API I realize that there is a lot of information that is not exposed to Python that would make my life much easier if it was. This is a perfect example. It would give add-on devs a more powerful set of tools to work with. Add-ons are, in some ways, the laboratories for Blenderâs future direction. If an add-on is wildly successful Blender may adopt its conventions internally. If not, it doesnât harm Blender if an add-on never gained traction. But without good hooks the add-on devs are sometimes hobbled in what they can do.
And generally speaking âPlease expose [such and such data] to the API.â is not going to garner a lot of votes as a Right Click Select proposal because most of the people on RCS wonât understand the meritorious value of a technical request for under-the-hood API features.
jeskeâs point #3 importantly reinforces that exposing this hook can be a great way to allow exploration with possible future directions without breaking current things. Even Blender itself could try a hybrid of one or two contextual menu entries without the workload of needing to redo the entire context menu system. If itâs well-received it could even allow for a slow shift over time from fixed actions that only work on active/selection (what we have now, which is just the header menus but next to the cursor) to a dynamic one that is truly contextual.
I think this can actually move forward without needing any sort of pre-highlight at all, even the âmomentaryâ one suggested in his point #2. (Although that would certainly be useful. Say, a third outline color different from the Active color or Selected color, like a light blue; only visible while the context menu is present on a non-selected object; disappears if the menu is cancelled.)
This is somewhat adjacent to general-purpose contextier context menus, but Iâve played around a bit with adding right click pie menus to custom gizmos, and Iâve found them to be incredibly useful for changing things like transform orientations and snapping modes.
They would be for tablet users, which I would assess are around the majority, at least among professionals ? Right-clicking with a stylus means hovering above the tablet surface, moving the index finger to reach the right-click button that sits about two centimeters above the middle button (which is how it is usually set up for convenience, since the middle button is arguably more frequently used, notably for navigation), and targeting the object. I know I make it sound like a complex choreography, but itâs actually quite annoying : the difficulty lies in keeping the stylus still, while hovering, and clicking (either by tapping the tablet surface, or not).
I actually believe the fault lies more on how the tablet and stylus are designed, but currently they are all made like this. I am not saying this to discourage anyone, but to help keep it in mind. Surely having menus react to whatâs under the pointer can be useful, and Iâll probably just rebind it to W or some easy-access hotkey.
