[Bf-committers] Declarative UI Experiment

[Ton Roosendaal]

Hi,

Not sure if I started this experiment, by complaining to Brecht and  
Campbell here that the UI scripts were getting out of control :)

Basically, I'm very happy with using Python for it, but - for our  
standard distro - with the absolute minimum of real coding there.  
Target is to make the layout system as smart as possible to handle  
most common cases well. The evident exceptions then can be Python  
scripted.

I strongly believe that individuals or organizations will come with  
own UI script configurations, sooner or later. By sticking for the  
official release to simple and understandable scripts, we can  
facilitate this... otherwise merging or updating will become too  
frustrating for them.

The freedom a Python script allows is then only a benefit for our  
users to use maximally, and a feature we should apply ourselves  
minimally. Nice workable concept, right? :)

My conclusion therefore: stick to what we have, but carefully check if  
there's improvements possible for managing the layouts more clearly.

-Ton-

------------------------------------------------------------------------
Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands

On 8 Aug, 2010, at 17:36, Campbell Barton wrote:

> 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