[Bf-committers] Declarative UI Experiment

Thomas Dinges dingto at gmx.de
Mon Aug 9 20:19:02 CEST 2010

  Hey everybody,
first of all I admit that I don't fully understand everything concerning 
this topic, but I want to say some words as the one who have written 
most ui scripts until today.
I did the initial ui python scripts back in summer 2009, after I did 
some "Hello world" stuff in Pythin and basic programms with some print 
stuff and variables. Nothing you can't learn within a few hours.
Even with that little knowledge it was very easy to get into the Blender 
Ui coding and in my oppinion it even got better over the past year, 
after some API changes.

So I think:
-We have a very easy api for Python ui scripts atm, where everyone can 
dive into it very easily and without much knowledge
-It has proven to work for 1 year now.
-All user-written scripts allready work this way, we should stop doing 
heavy api changes, or now in that proposal even language changes.

There are some flaws, I admit that, but it would be much better to try 
to improve the current method with pythons scripts, than completey 
change to another language.
I am very happy to help in any way, improving the current system.

Bottom line:
A big -1 for that proposal.

Best regards,

Am 08.08.2010 17:36, schrieb Campbell Barton:
> 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
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

More information about the Bf-committers mailing list