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