[Bf-committers] Declarative UI Experiment

Reuben Martin reuben.m at gmail.com
Mon Aug 9 05:38:13 CEST 2010


If you're defining a custom XML name-space for blender, would it be possible to embed python script within the markup as event handlers or registering callbacks? (Similar to how ECMA script is embedded within (X)HTML.) You could have the best of both worlds that way. Especially if you extend it to other areas (or create new name-spaces) where markup alone would be somewhat limiting.

-Reuben



Yo, back on Sunday, August 08, 2010 Campbell Barton was all like:
> 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)
> http://www.pasteall.org/14880/python
> http://www.pasteall.org/14879/xml
> 
> 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
> term)
>   (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
> drawn.
> - 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.
> eg:
> 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
> braces.
> 
> 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