[Bf-taskforce25] operators and context

[Matt Ebb]

On Wed, Oct 8, 2008 at 2:03 AM, Brecht Van Lommel <brecht at blender.org> wrote:

> Let's take a practical example, a "delete object" operator. In the 3D
> view the delete object operator would work on all selected objects.
> However you can also delete objects from the outliner, were it would
> work on the objects as selected there (selection state is completely
> separate here). One could also imagine a button that would delete the
> active object in the buttons window.
>
> There's a few possibilities to figure out this data:
> a) The operator is aware of the space it is running in, and knows that
> for the 3d view it uses the selected objects, for the outliner the
> selection state there, .. etc. Here you could have multiple operators,
> one for each case, or a single operator handling all these cases.
> b) The operator is directly passed the objects it operates on somehow,
> for example through a property of the operator.
> c) There is an abstraction that allows you to ask the context things
> like 'give a list of selected objects', and then the context can return
> different things based on the space, etc.

Hi,

Correct me if this isn't what you're implying, but I'm not keen on the
idea of tying operators to selections. It's not all the time that you
want to have a selection in order to do something. I can imagine it
would be very useful to have much more flexible tools that don't
operate on selections, but any other kind of inputs as well, for
example it would be great to have edit mode tools operating on
selections, or vertex groups, or moveable bounding boxes, like in modo
where each tool can use a different 'falloff' [1]. In modo these
different 'falloffs' can even be stacked and blended with each other
too for each tool. Very powerful stuff, and would make more complex
work a lot easier.

This is something that would really help Blender - right now this
reliance on selections, and weak selection tools make things a lot
more troublesome than they need to be. On more complex things, I
routinely wish for capability like making a tool work on contexts like
"the inverse of all faces with similar normals to my selection, within
a defined group of faces". That's a real world example, and the amount
of selecting, hiding, etc that was necessary to achieve that was a
real pain in the bum.

Also would this make it difficult to reuse the operators for the
python API, or is that on a lower level? i.e. I can imagine you'd want
to be able to pass an object or a list of objects to the delete
function, rather than having to select the objects via the API first.

In the case of the outliner too, you wouldn't just want a 'delete
object' tool either, ideally (which isn't available now, but should
be), you just have a 'delete' command that works context sensitive, on
whatever kind of data is selected. So you should be able to select an
object, a material and a few vertex groups and delete them all at the
same time. So perhaps in this case, the space would have to figure out
what kind of data is selected, and then send off the right inputs to
the relevant operators (i.e. send a list of selected objects to a
delete object function, a list of vertex groups to a delete vertex
groups function, etc etc)

Another thing to think about, which I'm not sure relates or not
(forgive me for opening a can of worms) is that it would be great in
this new system to support editing mixed selections, as opposed to the
horrid, clunky and limited 'copy attributes' system. I.e. as cessen
described on the bf-funboard here:
http://lists.blender.org/pipermail/bf-funboard/2008-June/004142.html

Anyway, sorry for raising more questions than answers, but I think
these kinds of things are quite important. The whole point of this
work is to make better and more powerful tools and workflows possible,
so it's good to think about how things should be done, rather than
just copying what's done currently.

cheers,

Matt


[i] http://www.kxcad.net/modo/Radial_Falloff.html