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 <[email protected]> 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 >> [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
