Re: Activate Scroll Key - More on mice/clicks/scrolls...

[Ric Klaren <ia_ric cs utwente nl>]

On Wed, Aug 19, 1998 at 06:34:41PM -0400, Tim Moore wrote:
> Even better, we could replace the traditional "mouse-1, mouse-2, ...,
> mouse-n" notation with a set of logical mouse buttons such as "Primary
> Button", "Contextual Menu Button" (for Win95-style right-click menu
> popups), "Menubar Button" (for GIMP/NEXTSTEP-style right-click menu
> popups), "Scroll [Up|Down|Left|Right] Button" (for IntelliMouse support),
> "Scroll Mode Button" (for GIMP-style drag-scrolling), and of course "Paste
> Button". Many others are possible. Apps are expected to respond to as many
> of these events as makes sense (GTK+ could probably handle most of them
> automatically).

I totally favour that. (already posted a similar remark a few days back).
New pointing devices would fit more easily into the guidelines.

> The fun part is that you get to map these to your physical mouse buttons
> any way you want. And there could even be saved "sets" which can be chosen
> from and imported/exported.

This would be something that should be configured gnome wide. And probably
a override option at the application level. Would take (I gues) some
changes in gtk and guidelines/hints (whatever) for WM's that advertise
gnome compliancy.

This would lead to something of:

A set of mouse/pointing device actions. For normal mice this would be
something like:

Mouse1 click
Mouse2 click
....
MouseN click

Mouse1 double click
Mouse2 double click
....
MouseN double click

Mouse1 drag
Mouse2 drag
...
MouseN drag

A number of user interface actions.. and maybe offer an application a way
to register certain functions for binding to mouse events. So a user could
adapt his mouse to better suit his needs in different applications. For
example a list to begin with:

Activate        (normal right button behaviour)
Context Menu    ('normal' left button behaviour)
Select Text
Past Text
Extend Selection
Scroll Object Contents X only
Scroll Object Contents Y only
Scroll Object Contents X and Y

Maybe even have some more for different widget types... Could be handy...
Could be overkill too.

A game for instance a flight simulator might add a action like:

Zoom  (would be handy for some wordprocessors/picture viewers too)
Increase Zoom factor
Decrease Zoom factor

The user could then bind these to the buttons of his liking.... During
install of the app or the first use of an app a user would get some message
that he/she might want to change some mouse bindings...

On Wed, Aug 19, 1998 at 03:14:10PM -0700, Dan Effugas Kaminsky wrote:
> This is a default evaluation here.  I really don't think that middle paste
> is a very good default, but it'd be suicidal to remove it totally.  Themes
> should control this.

Theme? Theme is appearance wasn't it? Or is it configuration options also?
Is it logical if you install a new theme and your key/mouse-bindings change?
Just a thought....

Ric
-- 
-----+++++*****************************************************+++++++++-------
- Ric Klaren - ia_ric@cs.utwente.nl ------- klaren@cs.utwente.nl --------------
-----+++++*****************************************************+++++++++-------
'And this 'rebooting' business? Give it a good kicking, do you?' 'Oh, no,
 of course, we ... that is ... well, yes, in fact,' said Ponder. 'Adrian
   goes round the back and ... er ... prods it with his foot. But in a
    technical way,' he added. --- From: Hogfather by Terry Pratchett.
-------------------------------------------------------------------------------

PGP signature