[Bf-committers] Declarative UI Experiment

[Elia Sarti]

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
>
>