traverso-devel
[Top][All Lists]
Advanced

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

Re: [Traverso-devel] keymap.xml patch


From: Remon
Subject: Re: [Traverso-devel] keymap.xml patch
Date: Tue, 20 Mar 2007 22:36:23 +0100
User-agent: KMail/1.9.6

Hello Ben, and welcome!

> I'm sure this is a common story, but I've been looking for an
> opensource audio tool like this for ages!
>
> And I love the power of the keyboard-based editing scheme.  I feel
> like it'll really allow heavy users to speed up their work.

Nice to hear that! It indeed is a powerfull concept, and much faster then 
menu/toolbox based interfaces, and we're improving it continuously!

> But when I first started using it, it was hard to do anything, since I
> didn't know the keys yet.  I found learning the interface to be a bit
> frustrating.  I felt like I could see the objects, but that they were
> ignoring me, which made me mad at them.  :)

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 !

> So I was thinking that a good way to help out new users without losing
> any of the power of the advanced interface would be to make more use
> of MouseButtonLeft.

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.....

> 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)

> 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)

> 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! ;-)

> 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

> But more importantly, how do these ideas sound to you?  I don't want
> to come running in late suggesting changes you don't like.  

Feel free to suggest anything you like!
We're very open for ideas and suggestions! What works for me doesn't have to 
work for you. I've tried to make things as flexible as possible, it's in fact 
even possible to write your own command plugin class, and use that to 
redirect key fact too, so you will be able to add new types of actions, or 
change existing ones!

It's rather easy to do, though one of course needs to get familiar with the 
code.
There is api documentation, and the mouse/keyboard event handling, 
dispatching, Command pattern and un/redo facilities as well as the 'jog' 
feature is documented here:

http://traverso-daw.org/developerdocumentation/index.html


> I'm just 
> excited.  :)

Heh, cool!

Greetings,

Remon

P.S.
The keymap file isn't documented at the moment, and few other things that 
might need more explanation, like creating Command classes. If you'd like to 
digg into this some more, feel free to join at #traverso or ask here, so I 
can  point you to the right locations!




reply via email to

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