[Bf-committers] Re: Proposed Tuhopuu stuff in 2.26
Tue, 28 Jan 2003 12:49:38 -0700
I've been mulling this over a bit ... I would never
be able to implement the modifications to the
features you recommend in time for the feature
freeze so the choice is then: a) accept them
'as is' but acknowledge that from a UI perspective
they aren't great, or b) work on them more first,
for a future version. This is a bit of a shame,
as having tested these features in a little project
I find they provide for some fast, efficient work
(which seems to be consistent with many other
popular UI elements in blender that may not
be too pretty. I guess in this sense they fit
right in ;).
As for diluting visual meaning, the scrollbars
already have frame numbers written on them so
I don't think I'd be the first one guilty of this
crime, and so the argument is then what is more
important: visual clarity or efficient use of space?
Anyways, I haven't quite decided what to do quite
yet. Are there any other opinions on this issue?
Has anybody actually tried these features in
Tuhopuu and love/hate them?
P.S. Thanks for your input on this.
>>*** Hos: Extra selection support for the action window, including:
>> - border select initiated in the channel names border
>> selects the channels and constraint channels.
>> - right click or border select initiated in the horizontal
>> scroll causes blender to select all keys for the selected
>> - right click or border select in the vertical scroll
>> causes blender to select all keys for the channel or
>> constraint channels that are to the left of the selection.
> In the interests of UI consistency, I think the horizontal
> select-all-keys-in-channel should be implemented like in the IPO window. The
> IPO window uses a vertical rectangular button next to the name of the IPO,
> to select all of the keys in that IPO. I've attached a mockup of how a
> similar system for the action window might look as actionwin_sel.png.
> It's generally a good idea to keep the UI controls' functions as distinct
> and well defined as possible (i.e. scrollbars are for scrolling only) to
> avoid confusing the user. If the same controls are used for many different
> things, it 'dilutes' the visual meaning that they communicate, so that the
> user can not expect what will happen when they use it, or what other hidden
> functions it may have.