[Bf-committers] Declarative UI Experiment

Campbell Barton ideasman42 at gmail.com
Sun Aug 8 17:36:47 CEST 2010

There are some concerns I have with the current UI code so yesterday I
looked into declarative UI's (Mozilla's XUL and some others) and wrote
a working, experimental XML method for defining panels/menus/headers.

Comparisons with render dimension and stamp panel (XML misses poll functions)

Before I go any further I should say that this is something I did in
my spare time yesterday because I wanted to look into an alternative,
its not a BF supported project :)
Also, I'm not especially interested in XML, This could be JSON, a
Python dictionary or our own markup.

The XML to RNA translator will currently run if you start blender in
debug mode (--debug argument). just to show this is working.
the script that does this is scripts/modules/bpy_xml_ui.py
notice it has no hard coded rna functions, the XML names are passed
directly to RNA so its just a thin wrapper.

Problems I see with the current python based UI
- heavy weight solution to a simple(?) problem - in many cases you
only define rows/columns containing static rna references.
  we are writing code for what is really a data definition.
  (note: in some cases its useful to write code for a UI rather then
just doing simple data deceleration, but perhaps this is an exception
which can be supported).
- no way to validate rna variables are correct.
- no way to edit the UI graphically.
- ties us too closely to python, requires we run python code to do a UI.

So after doing this test here are some pro's for this style of UI integration
- having declarative XML/JSON/YAML UI co-exist with what we have now
is quite easy (either for migration or to support both systems long
  (having 2 methods of doing UI's is annoying and in general I'd like
to avoid this)
- declarative UI supports having a graphical tool to create and edit
the UI where code cant be edited in a graphical tool, think how nice
it could be for someone with no coding experience to make a UI for
their rig, or to add options they use frequently into blenders.
 .... note, UI can generate code easy enough, just not edit once
generated - http://members.optusnet.com.au/cjbarton/obui/ObUI.png :).
- declarative UI means we can scan the UI and detect bad RNA paths for
example, at the moment you only get the error when the button is
- interestingly I found the XML version of the UI nicer in some ways
  * The columns and rows are anonymous, no need for variable names, I
quite like this.
  * The nested structure of the UI is better displayed in XML then by
python functions.

Some Implementation details/options
- However this works it should at least not be slower then the current
UI api stuff (easy enough to make it faster)
- XML/JSON translation into RNA could be cached and could be faster
then current Py UI
- since XML cant define expressions we could inline python in XML or
XML in python, but think this could get annoying. having external xml
files would be cumbersome IMHO.
  Just saying its not hard to mix this any way that suits us.
- Even though most of the time I find code logic in UI scripts to be
bad practice, it IS useful at times, can't ignore this. a declarative
UI is less functional.
- We could *optionally* replace python draw functions with a draw
dictionary, this lets us have the benefits of a declarative UI with
minimal disruption.
def MyPanel(bpy.types.Panel):
  bl_label = "My Panel"
  bl_draw_data = [
    ("row": ({"align": True},
      "column": ( ....... )
.... basically a list/dictionary which represents the XML linked
above, though I find the py version would use a lot of quotes and

Would be good to discuss this on the list and see if its worth
investigating further.

- Campbell

More information about the Bf-committers mailing list