[Bf-committers] Declarative UI Experiment

[Elia Sarti]

Yes generally I would have a patch already, but at the moment I cannot 
really afford spending 4 or 5 days working on some code and then see the 
whole thing sink into oblivion.

If there's enough interest from devs or users I could take the time but 
not just for a personal experiment, as I already know pros and cons of 
the language I drafted (and how it could work in practice).

Having some python prototype would not really give a solid reliable 
representation of what I think the final stage for the system should be.


Campbell Barton wrote, on 08/13/2010 08:12 AM:
> Hi Elia, I read over your document, if you like to look further into
> this would suggest this as a way forward, this is basically close to
> what I'm doing but so far I found its a quick way to test.
>
> * represent your language in python as simple types, list/tuples/strings
> * make a base class which you can mix in, it defines a draw function
> which takes this data from the class instance and draws it. (I did
> this with my test, its defined in bpyml_ui.py).
> ...now you have something working and can test the markup definition,
> convert panels etc, expect you could have this running in a day or so
> with<500 loc.
> * If this works well you could write a parser for your markup language
> and add it into the mix-in class so rather then defining a python list
> you could define a string or a filename reference.
>
> As I said before this is basically what I did except I made the data
> definition in python.
> But conditionals are not really covered so I'm most interested to see
> how this can be integrated into a definition/markup for existing
> blender panels.
>
> On Thu, Aug 12, 2010 at 9:17 AM, Elia Sarti<vekoon at gmail.com>  wrote:
>    
>> Well as I said a declarative alternative is not addressed at developers,
>> but normal users.
>> Simple cases for people with no dev knowledge means tough cases and more
>> difficult means absolute obscurity.
>>
>> I say this because I had a look at a couple 2.5 rigs and custom Python
>> rigging interfaces in these where anything but simple, and I doubt most
>> riggers know Python that well.
>> A declarative language as the one I drafted would make such interfaces
>> much simpler, mainly keeping you from doing a lot of checks just so you
>> don't get Python errors/exceptions.
>>
>> It's clear that this won't be a substitute for Python defined UIs, as
>> said many times. On the contrary, would just be a limited version of the
>> Python one, simply because it would (indirectly) use part of the API
>> while Python can access the API in its entirety.
>>
>> Again, automatic layout by data grouping wouldn't of course be a
>> substitute for manual UIs, nor it has ever dreamed of being so. Some UIs
>> are too complicated to be automated, but that doesn't mean you can't
>> automate simpler UIs. That's why I said only 70% would be avoided, but
>> still complicate UIs are the minority. By automating the simpler cases
>> you can concentrate more on the harder ones.
>>
>> The more time is spent in doing new things with what's there now the
>> harder it becomes to change things once we do have a clearer design.
>> Proof of that are UI scripts, there's so many of them that people are
>> reluctant in changing the way they work.
>> Maybe had the amount of UI Python code written so far been 30% in
>> quantity of what it is the introduction of a new system wouldn't have
>> been so badly received :)
>>
>>
>> Brecht Van Lommel wrote, on 08/11/2010 08:57 PM:
>>      
>>> Hi,
>>>
>>> I think this declarative UI is an interesting experiment, but in this
>>> state it also doesn't really address any important problems. In my
>>> opinion it's only useful when it's used for a GUI designer, there's a
>>> small improvement in readability for simple cases, but for more
>>> difficult cases with for/if loops it might also makes things more
>>> complicated. Going from one text based format to another only seems
>>> like a small improvement that is not worth the effort.
>>>
>>> Second, I think smarter layout engines and/or doing things based on
>>> data grouping is interesting, but I've always found these things
>>> fuzzy. Because it's all python code now it's pretty flexible to solve
>>> some things, also where perhaps the design doesn't fit so well. For
>>> example the theme user preferences or keymaps, or texture properties.
>>>
>>> We can of course say, well, then those things have to be solved then,
>>> cleaning up the design so the UI can reflect it properly without being
>>> confusing. That's great, but I also don't see a clear path to get
>>> there... only solutions to make the things that are already quite
>>> simple a bit simpler. To me it's more interesting to look into how can
>>> we make better list widgets, data block management UI, accommodate
>>> node based materials/textures/particles, etc, .. in a way that is
>>> consistent throughout the interface, easy to understand/use, and not
>>> hacked code.
>>>
>>> Brecht.
>>> _______________________________________________
>>> 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
>>
>>      
>
>
>