[Bf-taskforce25] Context and RNA
Brecht Van Lommel
brecht at blender.org
Mon Nov 3 14:10:06 CET 2008
Hi,
Michael Fox wrote:
> hi all, with the recent commit of the Data API and RNA i was wondering
> how context will be handled on a data level for disabling certain UI
> elements
>
> I propose, that each RNA property should have a Context attached to it,
> so that context can be accessed and compared to current context during
> UI drawing,therefore disabling its associated element. and such contexts
> could be accessed from python and checks during runtime of a script that
> the data is being used in the right context.
I think that RNA should only deal with properties being strictly
editable or non-editable. If a property is not relevant it should
still be editable, and hiding or disabling that property is an UI
level decision.
There are a few cases where a property is not editable that I can
think of:
* Library linked data is not editable. This is a matter of checking
id.lib in the datablock.
* Editmodes (mesh, armature, ..). Here the situation is a bit
complicated, where you sort of have the editmesh/editbones/..
overriding the regular data, but not entirely since some code will use
the edit data and some while use the original data. I'm thinking that
from the RNA API point of view, you could assume a Mesh having an
EditMesh pointer when it is being edited. Then if a vertex is
requested, it will look it up in the editmesh rather than the regular
mesh.
* Some properties may be driven by an expression or so, which makes
the properties themselfs effectively non-editable.
* Some properties may always be non-editable, for example it may be
interesting to expose the object matrix through RNA, but this is not
something you can edit.
None of these really require a context check, though I may be missing
some cases. Where I think the context really comes in is at a higher
level. You can think of a piece of code as doing one of these things:
a) Displaying data.
b) Editing data as part of a tool
c) Evaluating data as part of a node, modifier, constraint, ..
In case a) everything is basically read-only, it is just displaying
the data. In case b) you can only change properties that are editable,
but you can not change properties that are evaluated, i.e. an object
matrix cannot be set in a tool. In case c) you can change properties
that are evaluated, but never properties that are editable.
So this is the kind of context enforcement that I think we have to do,
and RNA should be able to provide information if the property is
editable, evaluatable, which can then be used by the python API for
example to check if changing some property is allowed. Checking if a
property is editable or evaluatable may require context, but where
exactly I'm not sure yet.
Brecht.
More information about the Bf-taskforce25
mailing list