mouse keys as shortcuts: how to label them?

[Brad Hards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 8 Jun 2003 06:22 am, Wout Mertens wrote:
> My mail to the xfree guys about this was never answered.
I am not a xfree guy, but I'll try to address the issues. Wout - I've 
rearranged your message a bit. Please try not to "top quote", as it confuses 
things.

> On Sat, 7 Jun 2003, Ellis Whitehead wrote:
> > Hi all,
> >
> > I've started working on a couple wish-list bugs
> > (http://bugs.kde.org/show_bug.cgi?id=34362 and
> > http://bugs.kde.org/show_bug.cgi?id=48062) relating to using the mouse
> > for shortcuts.  The two main requests are for using the side buttons for:
> > - back/forward in konqueror
> > 	- moving/resizing windows
> >
> > My question is how should we label the buttons?  I've only thought of bad
> > solutions so far.  It would be easy (but sometimes wrong) to do just use
> > the following:
> >
> > Btn	Label
> > 1	"Left Mouse Button"
> > 2	"Right Mouse Button"
> > 3	"Middle Mouse Button"
> > 4	"Scroll Wheel Up"
> > 5	"Scroll Wheel Down"
> > 6	"Left Side Mouse Button"
> > 7	"Right Side Mouse Button"
My MX700 has a left button, right button, clickable wheel (middle button), 
scroll up button (in front of wheel), scroll down button (behind wheel), two 
buttons on the left hand side (forward and rear) and another button behind 
the scroll down button.
http://www.ocaddiction.com/reviews/input/logitech_mx700/ for pictures.

> > Currently, buttons 4and 5 (as labeled by X) seem to be hard-coded to
> > scroll-up and scroll-down in Qt.  Some mice have extra buttons, but no
> > scroll wheel. In such a case, clicking one of the extra buttons is like
> > moving the scroll wheel one notch.  The hard-coding is quite unfortunate,
> > because it makes using mice with more than three buttons a pain to set
> > up.  However, there is no X function for querying which 'buttons' are for
> > the "ZAxis", as far as I can find, so I don't think Qt could rectify the
> > problem.
The core of X11 only does two relative axes (X and Y - its fundamentally a 2D 
system). The mouse driver knows how to map a Z axis to a couple of buttons, 
so you can use it. 

> > If I label button 4 "Scroll Up", then those users without a scroll wheel
> > will get falsly labeled side buttons.  Label it "Button 4" would be quite
> > confusing to the majority of users, though.
This is an inevitable consequence of configuring X to simulate button presses 
on a scroll wheel.

> > And there are of course special mice with many buttons, where this
> > typical button assignment might not apply at all.
There are mice where the functionality of buttons can be varied. For example, 
the "cruise control" (aka "smart scroll") functionality of some Logitech mice 
(eg MX700) can be switched off with a special USB control.  So it is a scroll 
wheel plus button in some modes, and button in other modes.

> > Unless the X developers implement a buttonmap framework (i.e. keymap for
> > the mouse), I don't think there will be any good solution.
As Wout pointed out, xmodmap can do this:
> This means that people with 5 button mice need to shuffle the buttons
> around for the wheel to work. How you do it is, you tell X:
>
>   Buttons 7
>   ZAxisMapping "6 7"
>
> and then you run once the display is up:
>
>   xmodmap -e 'pointer = 1 2 3 6 7 4 5'
What happens if you have two mice? If you have a spaceball? If you have a 
horizontal wheel?

> > I think the best course of action would be to go with the mapping I
> > listed above, since it'll be ok for most users.  An alternative would be
> > to set up a "button label configuration" page, but I'm not especially
> > inclined to do so.
The major problem is that you don't have the information you need to do the 
mapping above, unless you know what kind of mouse it is. The mouse driver 
gives you "button 6" semantics, not "right side button". The button could be 
anywhere on the mouse - you simply can't tell that from userspace (modulo 
some non-portable ioctls() that can get you a 10% solution, that we can 
discuss if you'd like).
Two options:
1. Just do it in terms of "button X", and have a little test application that 
allows users to figure out which button on the mouse is which, and present 
the user with button numbers
2. Have a database of mice, and let the user pick one, so you know which way 
the mapping will work. Also allow users to build a custom configuration 
(ideally in a way that allows them to send it to you for a future release).

> > Any suggestions are welcome, otherwise I'll go with the above for now.
> I think you can safely say that all programs assume that button 4 means up
> (or down, what was it).
5 is normally down, 4 is normally up.
However the scroll wheel only produces button 4 if you configure X in a 
particular way. Wout's suggestion of a better way to configure X is 
technically good, but unacceptable from a user viewpoint. For a start it will 
completely screw up non-KDE apps, such as Emacs, which rely on button4/5 
being the wheel.

> Frankly, I think all of this is pretty broken :(
Yep. There is a better way, but X probably isn't it.

Brad
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+5G2GW6pHgIdAuOMRAge8AJ9jzA8a13VeDI8nAGnhqy5xUV/gzQCbB77+
omMj9kaqIJkvDjO/zAdM+8k=
=9Pv/
-----END PGP SIGNATURE-----
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<