[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