traverso-devel
[Top][All Lists]
Advanced

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

Re: [Traverso-devel] Fade View classes added to CVS


From: Remon Sijrier
Subject: Re: [Traverso-devel] Fade View classes added to CVS
Date: Fri, 4 Aug 2006 15:32:24 +0200
User-agent: KMail/1.9.3

> > I think it's easiest to use 3 QWidgets in a verticall layout, the top and
> > bottomn will hold the labels in a horizontal layout, the labels itself
> > are inserted via QLabels'.
> > The center widget will be the viewport for the adjustments of the
> > fade....
>
> Good point. That would simplify the drawing routing quite a bit, because
> one wouldn't have to deal with TOPMARGIN and BOTTOMMARGIN all the time.

Indeed!
I'll see if I can add it sometime, let's first see how it feels to use it, 
maybe some more changes/improvements can be came up with so it can be 
included at once..

> > But I'm not sure if version 0.0.4 of jmbfade had more features/changes
> > then only the direction change ?
>
> Probably the distribution of the text labels (but it depends on what
> version you had before). In 0.0.4 the spaces between text labels are
> regular, which looks much nicer and avoids overlapping.

OK, this will be done automatically when moving to QLabels in a horizontal 
layout.

> I noticed two minor things when I checked it out yesterday:
>
> - Maybe we should use [D] to change the bending, because it's actually a
> drag action. At least that is what I did intuitively.

I've been thinking about this too.
What about [D] for adjusting both the strength and bend value at once?
You can use the mouse omnidirectional that way.
[S] for strength seems obvious, and can be kept, but [B] is a rather hard key 
to use.
I would suggest to still keep to have a Bending 'hold' action, maybe just 
[F] ?

Due the design of the contextual interface, most actions can be applied 
directly on the fadeview too!
(See <Q> on the fadeview, thats the one painted in the Clip)

Not really needed, but it shows the power of the architecture I think...

> All in all I really dig this solution. It encapsulates quite a lot of
> editing parameters in an appealing dialog which focuses on the visual
> feedback rather than on buttons and sliders.

It's indeed a very nice proof of concept for JMB dialogs!

Now towards a 10-20 band equalizer ;-)

> While we're at it, here's another suggestion:
> At the moment the left mouse button is hardly ever used. However, we could
> use it for the most obvious action ([D] in most cases) as an alternative to
> the regular key. This would let novice users to adapt more easily to the
> concept of soft selections. They would still have to learn it, because all
> other actions would require it, but they were at least able to do
> *something* the way they are used to.

I think that would be a good idea, also to add the "context menu" to the right 
mouse button.
There's however one big 'problem' with this approach, it doesn't 'force' the 
user to learn the concept, so they quickly start using the mouse and the 
menu's  'only'....
On the other hand, it does make Traverso friendlier for first time usage... 
(like you say, I should read more carefully heh)

Things that come into mind for mouse usage is "sensitiviness toggling"
Using the mouse buttons for [D] or <Q> makes mouse sensitiviness toggling 
implementation a lot harder.
But I don't know if it actually would work, an idea I had was to add mouse 
sensitiveness to the Command class.
The input engine knows when a Drag Command is active, and mouse left button 
clicks then can be very easily propagated to that Drag Command object....

Just an idea :-)

Remon

P.S.
Using mouse left button for [D], <Q> for context menu's and mouse right button 
for sensitiviness toggling....?




reply via email to

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