Re: [jokosher-devel] Click or shift click?

["Ben Thorp" <ben thorp gmail com>]

I guess my reason was that the shift+dragging felt more like picking up and moving - you "pick up" with the shift key, and move with the mouse, whereas current it's the inverse. Most application I've worked with use a drag as a selection, unless you've picked up a specific object - maybe the handle is the way to go.

Think about firefox - mostly a 'drag' will actually select, but if you drag a link it uses it as a bookmark.

Ben

On 2/7/07, Stuart Langridge <sil kryogenix org> wrote:

On 2/7/07, Laszlo Pandy < laszlok2 gmail com> wrote:
> townxelliot wrote (on bug 83186):
> > I'm not sure where the discussion is going on about the default left-
> > click behaviour (mentioned in the above comment), but I agree it needs
> > to be inverted: shift-click to move, click to select. It's very counter-
> > intuitive how it works at the moment.
>
> I'm not sure what to do about this, but I do know that I am biased
> towards the current behaviour because I have been using it this way for
> so long.
>
> Lets hear the pros and cons for changing it or leaving it the way it is.
> This will probably have to come down to a vote-with-your-gut unless
> someone can come up with a compelling reason (consistency with other
> apps maybe?) to go either way.

Clearly it's easier to click-and-drag than to shift-click-and-drag.
Clearly also there are two things that people want to do: move events
and select bits of them. I can't think of a way of doing this that is
as clear as assigning click-drag to one and shift-click-drag to the
other[1], so let's assume that the only options to be discussed are
what-we've-got-now and the reverse.

Selecting things is sometimes mapped to shift and sometimes not. For
example, you can just click-drag in a word processor to select.
However, you hold down shift to select bits with the cursor keys.
Alt+drag moves a window, so there's precedent for "modifier + mouse
drag" to move things, but no-one uses alt+drag so it's not much of a
precedent :) I don't believe that there's any clear and obvious
stand-out answer here; equally, I think that if we'd done it the other
way around from the beginning, we would have people complaining
because they thought that shift-click should select and it doesn't.

Two thoughts here, then. The first is: dragging is easier than
shift-dragging, so whichever one gets done most should be drag and the
other should be shift-drag. It's not clear to me whether people move
clips more or select bits of clips more. My instinctive reaction is
that they move clips around more. Speak up here, people who do audio
mixing in other apps, on what you do more and what they use. On the
principle of direct manipulation, if you click on something and drag
it around then it tends to move around; think of icons here, for
example. You directly move those by dragging them; I personally think
that clips should be the same, because you do move them around a lot.

Second thought is: lots of people are complaining. Therefore, the
current way is not intuitive for at least some people. Whether that
means it's bad for everyone is not clear.

sil

[1] we could have, for example, a "handle" that you have to click on
to drag something around, or use right-click-drag, but all these other
options that I can come up with are worse rather than better.

--
The carrot is hiding in your coat pocket.  "Don't let me be
eaten!" it begs in a pathetic, orange voice.
http://tinyurl.com/nvm9k
_______________________________________________
jokosher-devel-list mailing list
jokosher-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/jokosher-devel-list

-- 
Ben Thorp
mrben jedimoose org
"Carpe Aptenodytes"