[Bf-committers] Declarative UI Experiment

[Campbell Barton]

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
>



-- 
- Campbell