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 <[email protected]> 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 [email protected] 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 >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers > > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > -- - Campbell _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
