[Bf-committers] Declarative UI Experiment

Tue Aug 10 18:48:42 CEST 2010

To reply to a many of points made on this thread...

@Dan Eicher, preset poll functions are an option but some of the time
you need to write specific poll functions just for that situation,
this would get annoying if you had to open up a different file and
having an inline <script> seems cumbersome to me.
You mention replying the python parser with a C parser, yep, this is
always an option if a markup is used opposed to a language.

@Roger Wickes, not needing to learn python is kind-of good in one way
on the other hand its yet another language/markup to learn... as a
blender developer its not unusual to come in contact with with
c/c++/python/mediawiki/sphinx/cmake/make  so Im not all that happy to
add another to the list, mostly Im interested in a declarative UI & am
markup agnostic :).
- dumping a blend to XML via RNA is pretty easy and can be used for
diffs even if you cant re-open the XML in blender.

@Lars, I think we wouldn't go beyond embedded expressions in markup
and even that seems unlikely now.

@Joshua, have some ideas on how we could better improve tools to do
this but will leave for another post. Otherwise I find XML reads quite
well for our UI files (William agrees), but dont think its a point
worth arguing, most likely it wont be used.

@Dan Eicher, (again), 99% of panels are in python, currently we dont
have plans on converting ANY, but if we agree its worth testing
further I'd like to try get a set of panels (mesh/lattice for
instance) and convert them over manually to see how well it works.

@Roger Wickes, you mention HTML and CSS, while these are industry
standards, if your going to be doing anything vaguely technical with
blender (even making your own UI, which isnt a noob task no matter how
easy we make it), your going to want to learn python. The other thing
which makes me less interested in CSS is that Ton wants to make the
layout engine more powerful and the existing layout engine already
disallows absolute pixel positioning.
At the end of the day if we get a graphical layout editor the people
who use it wont care much what its markup is stored as.

@Thomas Dinges, as stated above, agree about the language.

@Elia Sarti, you say it may be worth to develop a very basic language,
if we went down this path Id prefer to do it in a way thats very
hidden to the user or developer (like pyc files), we could cache the
UI layout which is in a verbose/slow format into some simple binary
format that C can load. You mention gui designers being a big pain, I
never used a real one but I did use one that I wrote to do the 2.4x
OBJ i/o and FBX exporter, absolute placement of buttons by hand in
2.4x was so tedious that this proved worthwhile but with 2.5x nicer
layout engine I can imaging it could be a pain. Nevertheless there are
people who are not inclined to code and if we could edit existing
layouts I think it would help at times (a rigger making their own UI
for eg).

You mention how we could have 1 much more limited way to build UI's,
Id need to see some example of this to understand.

@Jason Wilkins, The problem with a GUI editor and code is to edit an
existing UI, a GUI editor that generates code is not a problem.
When I talk about re-implementing in XML,  I mean re-implementing
existing python scripts, of-course we would use an existing XML
parser. The complications would come from the limitations from a
different method of writing a UI.

@Doug Ollivier, yep we could make a 2.5 python code generator without
much trouble + a UI editor toolkit. a few were made for blender 2.4x,
but IMHO the big advantage would be to be able to edit existing UI
panels.

@José Romero, I normally find python quite readable too, but in this
case we have a data structure which defines nested UI elements but
python has 1 level of indentation. recently I made some examples of
python deceleration, also we're not really worried about security in
this case.
Agree about the middle ground GUI tool for + python for devs who
probably want the extra control anyway.

On Tue, Aug 10, 2010 at 10:32 PM, Elia Sarti <vekoon at gmail.com> wrote:
> Maybe I'm wrong but I think the major job would be converting all the
> draw functions, not creating new files or polls. Especially considering
> that to my understanding polls are there just to keep you from
> instancing or always calling the draw function, which would be simpler
> in a declarative language.
>
> Again I think the point is work required vs how better it gets and I
> don't think changing one function to a dictionary will make it much
> easier to regular users and definitely not easier for developers.
>
>
> Campbell Barton wrote, on 08/10/2010 01:14 PM:
>> The second python markup example was just made up using python like
>> syntax so I had a go at making the declaration into working python.
>>
>> http://www.pasteall.org/14923/python
>>
>> To show its an XML equivalent theres a XML conversion function as well
>> (output at the bottom).
>>
>> Elia, using a python based definition inline just means we can keep
>> the same classes and don't have the hassle of creating a whole new set
>> of files, getting the poll functions inlined in XML (or similar).
>>
>> On Tue, Aug 10, 2010 at 8:03 PM, Elia Sarti<vekoon at gmail.com>  wrote:
>>
>>> How does this make it more like what we have now?
>>> You'd still need to rewrite all UI scripts from scratch.
>>>
>>> As I said to avoid having two different ways to do 1 thing you simply
>>> let Python have full control of the layout system itself (even leaving
>>> the same exact API as now, just adding some more) so if you're a Python
>>> developer you can do everything in Python, while if you're a user you
>>> can use a simpler declarative language (but our own integrated custom
>>> language, not XML).
>>>
>>>
>>> Thomas Dinges wrote, on 08/10/2010 07:47 AM:
>>>
>>>>     Hey Campbell,
>>>> my main -1 argument was because of the big language change.
>>>> Also i was afraid of then having 2 files for a script (a py file for
>>>> operators and 1 xml file for the ui)
>>>>
>>>> The first 2 versions you propose now are much better than the xml
>>>> version in my oppinion.
>>>> I even would prefer the second method, as it is much more readable.
>>>>
>>>> As I said, let's focus more on what we have now and make changes to that.
>>>>
>>>> +1 to that now. ;-)
>>>>
>>>> Am 10.08.2010 05:34, schrieb Campbell Barton:
>>>>
>>>>
>>>>> As I feared the 'XML' topic came up, and without replying to each
>>>>> statement made above lets just say its a very different direction to
>>>>> the one we have been going in and I can understand resistance.
>>>>>
>>>>> The original spec for 2.5 was that we would have a UI layout defined in python,
>>>>> So here are 2 examples of python defined declarative UI's which could
>>>>> fairly easily co-exist with what we have now.
>>>>>
>>>>> - basically a python version of the XML panel
>>>>> http://pastie.org/1083109
>>>>>
>>>>> - this is python also but relies on having some custom classes defined
>>>>> which would expand themselves into the data structure above. Its nice
>>>>> in that it is much easier to read/write, but its also not pure python.
>>>>> http://pastie.org/1083111
>>>>>
>>>>> - original XML for reference.
>>>>> http://pastie.org/1083129
>>>>>
>>>>> For those who gave the proposal a -1, what about one of the 2 methods above?
>>>>>
>>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>>
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>

-- 
- Campbell