[Bf-committers] Declarative UI Experiment

[Campbell Barton]

This started because I was finding the UI code hard to follow and
wasn't a fan of the wide_ui checks which added many if's in what would
otherwise be quite simple.

A number of times though this thread I have stated that this can be
tested without disturbing the rest of blender's UI scripts, so I find
a few replies somewhat alarmist.

So!, after saying all that - I have one of the python examples working
in blender now!
http://pastie.org/1086175

A while ago I posted 2 possible syntax's http://pastie.org/1083109 and
http://pastie.org/1083111
Interestingly the pretty syntax just expands into the ugly one :) - so
both will work.

For now I'm not aiming to convert scripts in blender but can have this
as something addons can use & possibly help with writing a GUI
builder.
This is opt-in, if the module is not imported the file isn't even read
from the disk when blender loads so I think its safe to test this in
blender at this level.

On Wed, Aug 11, 2010 at 11:38 PM, Ton Roosendaal <ton at blender.org> wrote:
> 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
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell