[Bf-committers] Declarative UI Experiment

[Elia Sarti]

Hi,

Sorry for the long absence, I got a little busy lately but hopefully 
will be more active in a month or so. I thought this is an important 
enough issue I should take some time to throw in my humble opinion.

As it has already been said the problem of XML is verbosity while JSON 
and YAML are confusing from my perspective.
I believe the main issue here is all of these are data serialization 
languages, meaning they're used to define data itself, while in our case 
we just need to visually structure data that's already been defined 
elsewhere.

If we want a declarative language I think we should develop our own 
*very* basic structuring language, so we could make it RNA aware and 
have layout declaration and text labels in different files, for easier 
localization.

 From personal experience GUI designers are always a big pain, so much 
that I generally prefer code-only solutions. I think they're limited and 
hard to control and they seem more useful in theory than they are in 
practice.

I agree that using a language like Python for just declaring UIs seems 
overdoing it BUT only if we stick to simple UI structuring; if we allow 
logic to be evaluated (injecting python expressions into a structuring 
language) then I don't see how the problem is solved.
Judging by all the COMPAT_ENGINES stuff, polls and checks that are 
currently done in UI scripts it seems like we rely a lot on flow 
control, thus simply translating this from a Python version to an hybrid 
structure/python is not a very efficient solution in my opinion.

Personally I'd rather have much more limited layout customizations and 
then develop some way to plug into the layout using Python add-ons.
The only logic I would allow in these structure files would be checks on 
values to show/hide or enable/disable.
An add-on could register and hook into the layout system and have total 
control like it is now for UI scripts but structured and not sequential.
This way we would only have 1 way to build UIs, with our simple 
structuring language, but still leave a window to those needing heavy 
customizability by using what would just be a part of the API (that 
could be extended for e.g. with custom Python layout templates, as in ID 
or List template).

That being said the one big problem to consider is the amount of UI py 
scripts already written, functional and well tested. I'm not sure how 
feasible a conversion mechanism could be (probably not very much) nor 
how many custom scripts users have developed during this time.
It is also true though that 2.5 as said from the beginning was a 
transitional stage so maybe it is OK to break such compatibility if we 
develop a better system. Also old users' Python scripts could be adapted 
easily (and temporarily?) to the add-on system I talked about.



Campbell Barton wrote, on 08/08/2010 04:36 PM:
> 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
>
>