Re: [platform-ui-dev] Re: Opera/Mozilla style mouse/pen gesture recognit

[Randy Hudson <hudsonr@xxxxxxxxxx>]

4) If I'm going to press the Control
Key, why can't I also press S for save? If you goal is to not use the keyboard,
It would make more sense to ignore Motif's convention.  I wish we
could all ignore it, and popup the menu on mouse-up.  In GEF, it would
be nice to be able to drag an object with the right mouse button like in
Windows, and get a popup menu at the end of the drag with choices like
"Move", "Copy", "Create Shortcut".

5) Here's an idea.  Change the
cursor to something like a pen, that way the User will know (however slightly)
sooner that the gesture will or will not be recognized.  Perhaps paint
the "ink" on the screen, and possible display the interpretation
as well.
Much like Undo and Redo, getting this
to work for an Editor with 100 Controls (like PDE) will be challenging.

"Chris McLaren" <Chris_McLaren@xxxxxxx> Sent by: platform-ui-dev-admin@xxxxxxxxxxx 11/28/2002 12:21 PM Please respond to platform-ui-dev

To:        platform-ui-dev@xxxxxxxxxxx         cc:                 Subject:        [platform-ui-dev] Re: Opera/Mozilla style mouse/pen gesture recognition in Eclipse

>This feature sounds like a waste of effort.
>
>1) No one is asking for this or really needs it
>2) Eclipse is not a web browser
>3) The right mouse button is used for the context menu 999 times out
of 1000.  That means that it is very likely a gesture will be incorrectly
recognized when the user is just trying to get the >context menu to
appear.  Also, the results of a gesture having been interpreted are
unexpected and/or subtle. 
>4) This doesn't work on Motif.  The context menu must appear on
mouse down. 
>5) This creates either an inconsistancy or unwanted work for people
writing Editors that aren't AbstractText editors.

I appreciate your opinions. Here's my point-by-point response:

1) You are correct in that no one asked for this feature, at least as I
far as I can recall. The responses on the mailing lists from people who
use Opera or Mozilla indicate however that this feature would be a welcome
addition. Whether a user might 'need' this feature should really be a decision
left to the user, no? 

2) Treating new input methods as web browser specific simply because web
browsers were the first to implement them is *terribly short sighted*.
This sort of thinking is the death of invention. Here's a link suggesting
that the though the web browser gave birth to this feature, it might be
ready for prime-time in other applications. There is also a link from this
page to a user study on mouse gesturing: 

http://news.com.com/2100-1023-960408.html?tag=fd_lede

Furthermore, I would object to the idea that Eclipse doesn't 'browse'.
In fact, the very reason I thought to try this was I thought it might be
complementary to the new very-cool hyperlinked code feature - which undeniably
adds a 'browser' feel to Eclipse editors. 

3) Have you tried the feature? You may find that care was given in the
implementation to ensure that it is *not* 'very likely' that a gesture
will be misinterpreted for a context-menu-invoking right-click. From the
right-click down, the mouse must travel a minimum of 20 pixels before gesture
recognition is attempted, after which any unrecognized gesture will still
invoke the context menu. If the user has the option to turn mouse gestures
on, and they are off by default, haven't we really covered the bases here?

4) It works, but the platform feel is broken. I think we have enough possible
solutions from the mailing list community to make it work correctly, such
as requiring a modifier key in combination with the mouse down.

http://dev.eclipse.org/bugs/show_bug.cgi?id=27232 has been logged.

5) True enough, it would be nice to have first grab at the mouse across
the application but SWT doesn't support this. Perhaps allowing controls
to choose whether they want to support gestures isn't a bad idea either.
We should definitely look at making easy or even automatic for other editors
to use the gesturing support. For this experiment, for instance, only one
method needed to be modified within AbstractTextEditor, indicating that
generalized support for this feature may not be a difficult task.

Chris.