[Bf-committers] Declarative UI Experiment

[Elia Sarti]

Hi,

Sorry, last night I couldn't make it, was too tired, will try and take 
some time today to get the "proposal" up.

As Benjamin says the reason behind Campbell's proposal is that the 
current system is easy only for developers and even if someone can just 
build Blender on his own, I put him in the developer range as most 
people wouldn't be able to.

So the whole point of introducing a parallel easier system is to meet 
the needs of that majority of people, while leaving the current Python 
API as it is (or just with some slight additions) for devs.

What we do with the internal UI files is just our business, the goal is 
to allow people to overwrite that UI without the need to go and change 
the original files but just adding their own.


Benjamin Tolputt wrote, on 08/11/2010 09:30 AM:
> Michael Fox wrote:
>    
>> There is one thing here that no one has seemed to have mentioned is we
>> are close to release date, and 2.53 has already become the defacto
>> standard of blender,
>>      
> Well, Blender 2.53 *IS* still in beta. I too am using it and wish at
> times it would settle down a bit, but just because we wish it to be true
> doesn't mean we can (or should) enforce this to the detriment of
> features being developed / nailed down.
>
>    
>> This fact is multiplied due to the advanced Python centric of the
>> proposed methods as this limits simple changes to those who know what
>> they are doing where as  the current api is easy and changed quickly
>> with copy and paste and the like. Like i have very little python
>> knowledge and i find the currently api much more understandable then
>> proposed methods, and view the current api as far more flexible.
>>
>>      
> Well, I think this is the crux of the matter. For developers, the GUI
> API stuff is simple. For non-developers (i.e. the artists one posits are
> kept in mind when developing Blender) it is apparently not so simple and
> understandable.
>
> I have no problem with making it easier for artists to put together a
> GUI to control rigs. Whether this is through a dedicated tool, an easy
> to understand "declarative" syntax, or something else is up in the air.
> However, I can tell you over 75% of the people I help with Blender
> understand only the most basic Python expressions - the GUI code is
> going to be beyond them.
>
>    
>> any proposals to mix methods will only achieve utter confusion on behalf
>> of the user and any budding developer as they would not know what to use
>> and would be aggravated by the shear lack of consistency and consistency
>> is a corner stone of 2.5, and in recent times i have seen it thrown out
>> the window without a care.
>>
>>      
> This I agree with. Mixing XML with Python is just a disaster waiting to
> happen. On the other hand, the declarative style Python example shown in
> a previous email (I remember it was the second screenshot) works well.
>
>    
>> So i propose is keep the api that we have, instead adjust and optimise
>> what is behind there and all these arguments about speed, its not the UI
>> falut, its improper use of notifiers and redraws, which has been
>> completely ignored or over looked, i view these new UI proposals as
>> putting a band aid on a broken leg with the main issue being ignored and
>> many agree with me.
>>
>> This also look to me like over adjusting and concentrating on somthing
>> that shouldn't be, there is a huge bugtracker out there you know
>>      
> Well, people work on what they want to - it is open source after all.
> This from someone who has been disappointed in the past with development
> directions myself. Combined with the fact that if we "left things as
> they were", Blender 2.5's configurable GUI would not have been put
> together in the first place. The only way to move forward is to make
> changes... if it cannot be done prior to a stable release - when will it
> be done?
>
>
>