Re: [Traverso-devel] keymap.xml patch

[ben levitt]

On 3/20/07, Remon <address@hidden> wrote:
> Hello Ben, and welcome!

Thanks!

(Caution: my usability ramblings below...)

> Heh, now I thought the cvs version has improved a lot compared to the last
> release (0.30.0), but I agree that it's confusing that clicking on 'buttons'
> and other objects doesn't do much !

I agree that current cvs is way improved over 0.30 !  I think that one
of the largest improvements is that in cvs, traverso is beginning to
allow users to interact with objects using the mouse buttons.  Having
the right button pop up a context menu is great.  And having the left
button drag clips is great too.  It's exactly these kinds of recent
improvements that I think should be expanded upon.  :)

> Like Nicola pointed out, we'd like to somewhat 'force' the concept since it is
> so powerfull, and people most likely will keep using the menu system only
> instead of using the keys.
> Keyboard keys are logically grouped, so learning one key, and how it is used
> also gives a clue how other keys are supposed to be used, and what their
> function is.
>
> The user manual should help new users a lot I think, and maybe there will be
> another medium to show the users how to use traverso.
> Your help of course is much appreciated, first user experiences are highly
> welcome, specially since I had the idea that the learning curve has dropped
> by a large degree in respect to previous versions.....

So... in my day job, I work as a user interface designer, and some of
the things we're constantly looking for are ways to help make
applications just work the way people expect them to, as opposed to
making the user fight the app, or adjust to the way the application
wants them to work.  I also believe that a gui app that requires the
user to read a manual in order to even begin using it, will definitely
push a lot of users away.

I totally understand the desire to get people doing things "the right
way" from the beginning, but I really feel that forcing users to do
things the way you think is best, instead of just trying to do what
the user wants, can only backfire on the project.  :(

> > I like the idea of heavily loading the behavior of the left mouse
> > button with basic object-interaction commands, like moving clips,
> > moving curve nodes, moving clip edges, moving track marks, moving the
> > scrollbar, setting the position of the work cursor,
>
> Well, there is nothing wrong with that I think, and the InputEngine is
> flexible enough to make this work with a couple of lines (as you are aware of
> allready hehe)

I think that current cvs is moving in the right direction by allowing
use of the mouse buttons to do basic things, and I love how this kind
of "beginner" interface can be added without hurting expert users at
all.

And yes, the InputEngine's flexibility is really cool!  It's been fun
and easy to tweak the keymap to start making it work the way I wanted
it to work.  :)

> > selecting clips
> > (does selecting a clip actually do anything in this soft-selection
> > framework?), etc.
>
> Hah, good catch! You're the first one (iirc) that brings this up!
> It for sure has a function, though it isn't used much right now.
> One could think as adding it to the selection 'group' and moving a clip in the
> group moves the whole group, deleting clips is currently done for clips in a
> group (so you have to select a clip first before you are able to delete it)
>
> But nothing prevents you to use a different way to delete clips, it most
> likely is just as simple as adding another entry in the keymap file ! (or in
> combination with a simple new Command class)

Oh, okay.  I couldn't figure out how to delete clips.  I was going to
ask about that later.  :)  But since you bring it up, I was thinking
that there should probably be a way to delete a clip in a similar way
to deleting a curve node, track mark, or track.  (as a command
performed on the clip itself... maybe also mapped to <<R>> for
consistency?)

But back to selections and grouping, I agree that selecting a bunch of
tracks and then moving one of them should move them all.  I wonder if
that concept could be abstracted out so that if you perform a drag
action on a clip that is part of a selection, all selected clips are
affected in the same way?  Edge drags, gain adjustments, etc...  That
probably only makes sense for some of the commands...

> > I made a small patch to keymap.xml that implements most of this (cvs
> > diff -u), and it's attached.  Please let me know if you prefer a
> > different format, or a different delivery method.  (Bug/patch
> > tracker?)
>
> Savannah has a number of tools to post bugs/patches/wishes, and so on.
> If you like to work more on Traverso, we could of course look into other ways
> to have your work merged upstream! ;-)

Okay, I'll just post patches there.  :)

> > You may notice the line that references objectname="AudioClipEdge".
> > It currently does nothing.  Any suggestions on how to implement
> > dragging an edge if the mouse click started near an edge?  I was going
> > to try to have the AudioClipView check how close the mouse pointer is
> > to an edge, and then dispatch the correct event, but I haven't read
> > through enough of the code yet to figure out how InputEngine and
> > friends are dispatching events.
>
> AudioClipEdge isnt' an object indeed, so it won't work. AudioClipView itself
> is the only one that knows about it's geometry, so that is the one you need
> to detect to which edge the mouse is nearest.
> Since MoveEdge allready is implemented, it should be sufficient to copy paste
> the [ E ] entry in the keymap file (let me look that one up)
> Ah:
>
> <Object objectname="AudioClipView" mousehint="LR" slotsignature="drag_edge"
> modes="All" sortorder="8" instantanious="0" />
>
> Now, the only thing you have to do is adding this line for the keyfact:
>
> <keyfact type="HKEY" key1="MouseButtonLeft" >
>
> (HKEY : Hold Key type)
>
> And voila, dragging the edge works for the mousebutton too.... But oops,
> dragging the clip with the mousebutton no longer works.....
> So, I would suggest to use [ D ] (Drag) for that now, or perhaps [ E ] (
> Edge ) is still easier ?  :D

:) I guess what I was thinking was that it would be cool to have the
mouse work such that starting a drag from within a few pixels of the
edge of a clip would drag the edge, but a drag that started from the
middle of a clip would drag the clip.

I was thinking that maybe AudioClipViews could have invisible child
views (AudioClipEdgeViews?) at each edge that were just a few pixels
wide, and that could receive events directed at them...  This would
allow for even greater UI flexibility.  :)

I also though a similar approach might work to allow the things that
look like buttons and sliders in the Track headers to be usable by
beginners.

And then to teach people the right/advanced/un-guessable way to do the
same thing, we could have tooltips and status bar messages while
hovering over a pseudo-button or -slider, that tell people how to use
the advanced input method for adjusting the relevant property.

I'm worried about the current usability of the items in the Track
Header, since I think they currently seem like door knobs that don't
open the door, or a switch on a lamp that doesn't actually turn it on.
:P  The way they look invites users to click on them, so I think we
should acknowledge their interaction attempts, and try to do the right
thing if we can.

Thanks for listening to my ramblings!

Ben