Ideally there would be no change, and there is already a way to do this which can be packaged into an API command.
What I’d expect is a simple, short, context-, mode-, type-, and state- independent method to report all the scene data which is selected. I am not aware of another 3D application with an API which lack this functionality. It’d look like: bpy.utilities.get_selection()
. Additional filtering would be nice-to-have but not necessary for basic function, as there are existing ways to filter after the fact.
Feel free to expand on these assumptions you are referring to, as I am not sure what they are.
Examples of? I am a bit confused by this question. There’s a bunch of data in an open scene, which exists regardless of context, mode, type, and state. At any one point in time, some of this data is selected, and some isn’t. Report what is. AIUI, in order to do this currently, you need to traverse context and states, sometimes in a way which alters the selection, as another developer reports above. So, this would need to prevent the selection from being altered as well.
Here is an example of where this is already a convoluted problem, for a single data type (vertices) out of what I assume are dozens or hundreds :
If the user is in object mode and has two verts selected, and runs the get_selection()
method, if for some reason, the method must enter edit mode in order to check on some other type of data which isn’t available for query in object mode (similar to the way that C.object.vertices[x].select isn’t available in edit mode), and those two vertices happen to be connected to the same edge, when the state is restored to object mode , that edge will now be selected. So the command also has to record which components are selected (and not selected) before entering edit mode, and restore that selection state once returning to object mode. This is just a single example mind you, and IMO it means that authoring a universal get_selection()
method via the API is not appropriate, because if it’s representative of how other context-, and mode- traversals are going to function, it’s going to be cumbersome and fragile. I assume there are ways to sidestep issues like these (because clearly there’s a representation in memory of everything which is currently selected…right?), but I won’t know how to do that, and I expect that a lot of it won’t be accessible through the API anyway.
If, in order to discover what’s selected via the API, you have to alter the state of the application in a way which also alters the selection, there’s a fundamental problem.
Maybe you are asking about the format it should report data in? I’d say a list of object pointers would be simplest, but I am not really up to speed on data traversal conventions in the API, and convention in this context would be more important than whatever I might imagine (e.g., a dictionary of types! a dictionary of contexts! etc), so that a veteran would find it somewhat intuitive to acccess.
In a perfect world, it’d be an object itself, and not a standalone utility method, but this is more complex to design. If I were designing a 3D application from the ground up, selection would certainly be a class hierarchy with intuitive traversal built in.