traverso-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Traverso-devel] Re: audio clip selection behavior


From: ben levitt
Subject: Re: [Traverso-devel] Re: audio clip selection behavior
Date: Tue, 20 Jan 2009 15:49:01 -0800

Hi everyone,

Remon - yay for all the changes!  I'll test them out here soon.  A few
comments below:

On Mon, Jan 19, 2009 at 2:09 PM, Remon Sijrier <address@hidden> wrote:
> Hi Peter,
>
>> > When un-doing the remove action, the selection is not restored, maybe it
>> > should be ?
>>
>> Generally, the undo feature promises to the user that a certain action is
>> undone in such a way that the previous state is restored. So, when an
>> entire selection got removed, as user I'd expect that the entire selection
>> gets restored when undoing the removal. So, in my opinion, the entire
>> selection should be restored (and maybe even selected).
>
>
> Sure, the entire selection is restored, I meant the restored selection isn't
> set selected again.

I think the selection state should be restored when undoing the
deletion of selected tracks.  Because if you select some clips, and
then Delete Clips, and then undo, then doing Delete Clips again should
do the same thing it did before.  :)


>> > Keys used to select and de-select audio clips:
>>
>> Here some radical, spoil-your week[end] ideas: How feasible would it be to
>> model selection behaviour on the lines of what's already done in the file
>> browsers in Windows (Explorer) and KDE (Konqueror)? It seems that other
>> apps have taken this selection behaviour on as well - I think, Cool edit in
>> its multitrack editor for example (except that they use the shift button
>> for multiple clip selection). Generally, selection is one of the
>> all-pervasive features, so to decorate it with special shortcuts seems
>> somewhat strange to me (if I put my user's hat on). In particular, how
>> feasible would it be to implement the following features:
>>
>> * Map "Select clip" to the left mouse button
>>
>> * Offer a 'rubber band' selection method: user moves mouse to a point and
>> then drags the mouse whilst holding the left mouse button. This then draws
>> a rectangle and every clip tpouched by the rectangle gets selected.
>>
>> * Map "Add clip to selection" to ctrl-leftMouseClick.
>>
>> * Have a clip removed from a selection by ctrl-leftMouseClicking a selected
>> clip.
>>
>>  > The idea is that 'hard selecting' clips always means we want to select
>>  > more then one, to perform an action on multiple clips at the same time.
>>  > This way selecting multiple clips can be done fast and without a worry
>>  > to accidentally deselect the selection, which often happens in other
>>  > software when clicking the mouse outside the to be clicked object's
>>  > region, or when not holding the CTRL key firm enough :-)
>>
>> I found that the CTRL key usually works fine (e.g. in Cool edit). The
>> problem of a non-functioning CTRL key is located within user space, not
>> within developer space (Oops, sorry, sounds too scientific :) ) I mean -
>> the solution to the non-functioning CTRL-key isn't something we can do
>> something about. Only the user can remedy it by aquiring another keyboard
>> or pressing the CTRL key harder. Sounds unfriendly, but any other key could
>> fail just as much as the CTRL key (e.g. the 's' key). One of the best
>> keyboards I have has a non-functioning '1' key. I wouldn't dream of asking
>> the app developers to develop a solution around that.
>
> I understand your pov, but note that 'hard selecting objects' has a somewhat
> different meaning in Traverso.
> Mapping to left mouse button is no problem, you can map to any key/mouse
> button, but then we're back at moving so many (if not all?) to the mouse
> buttons again, which I tend to dislike ;-)
>
> Well, I think the best way is to just try it out, and see how it works out,
> anyone else any comments ?

I actually agree that <left mouse button>  (but not [left mouse
button]) should select a clip.  And Ctrl-<left mouse button> should
add/remove the clip from the set of selected clips.  We could have
other keys do that too, but we might as well make use of what users
already expect where we can.  And I think this is definitely something
that users will expect.  But I also agree that we should try it out
and see how it feels.  :)  I think it will feel right, but I could
imagine that it might make it harder to move a clip, or make it harder
to keep a set of clips selected if an accidental click deselects
everything...  It'll be a fun design issue to play with.

Ben




reply via email to

[Prev in Thread] Current Thread [Next in Thread]