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<[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 >> >> > > > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
