[Bf-taskforce25] Widget Colouring Suggestion

Ton Roosendaal ton at blender.org
Mon Apr 6 15:21:07 CEST 2009


Hi,

> These special state-widgets, just like text outside buttons, work 
> nicely in layouts that are strictly displayed as a list

Such features can be part of "Style" definitions, so it can be added 
where appropriate.

Further there's plenty of subtle ways to explore; here's a quicky I 
did, the button outline code is a quad strip, so can be any width;
http://download.blender.org/institute/rt.jpg
Or just color items in button:
http://download.blender.org/institute/rt2.jpg

Still; a problem with color coding remains that you have drop (part of) 
the freedom to assign colors to visualize widget types. Color encoding 
is very limited and with more than just a few colors it starts looking 
messy and loses meaning.

-Ton-

------------------------------------------------------------------------
Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
Blender Institute BV  Entrepotdok 57A  1018AD Amsterdam The Netherlands

On 5 Apr, 2009, at 21:03, William Reynish wrote:

>
> On 5 Apr, 2009, at 12:49 PM, Ton Roosendaal wrote:
>
>> Hi,
>>
>> This is of course a temporary situation. We're experimenting with it. 
>> :)
>>
>> The basic idea remains that widget coloring will be derived from a set
>> of theme colors you've defined yourself, visualizing widget
>> functionality or widget types, and matching the overal looks you want.
>>
>> We will also check smaller and more subtle ways to show animated
>> variables. We could make the layout engine add space for a small
>> icon/button, allowing standard input methods to edit it, and visualize
>> whether the variable has a function curve, is being driven, or
>> controlled by expression, and allowing a way to make a function curve
>> editor to show the curve/driver.
>>
>> One thing is quite cool of the current flashy coloring though; it's
>> totally clear and obvious for debugging purposes. Might be worth
>> putting a theme option in Blender that does it, so you can optionally
>> switch to it on a simple command, and back. :)
>
> We have to find a balance where this information is as clear as 
> possible, yet not totally distracting. Current solution isn't too bad 
> I don't think - like you say it's obvious, yet non-intrusive whenever 
> that information is not needed or not focused on - buttons that are 
> not animated keep looking normal. However, I appreciate that 
> there definitely are other solutions and it'd be nice if anyone with 
> other ideas could scribble them down and preferably do some visual 
> mockups of buttons in animated/expression/keyframe/driven states.
>
> The problems with having a separate icon for animation states 
> are twofold: first, you have to create a visual connection between it 
> and the 'parent' widget, and second, you have much more clutter and 
> information in the users face. These special state-widgets, just like 
> text outside buttons, work nicely in layouts that are strictly 
> displayed as a list - a la Apple Motion, XSI, etc, but probably not so 
> much in Blender where buttons layouts so far are a lot more varied.
>
> -William
>
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25



More information about the Bf-taskforce25 mailing list