| Summary: | mouse button mapping / handedness control is inflexible | ||
|---|---|---|---|
| Product: | [Unmaintained] kdelibs | Reporter: | John Belmonte <john> |
| Component: | general | Assignee: | Stephan Kulow <coolo> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Debian testing | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | 62268.diff | ||
Buttons 4 and 5 are hardcoded to the wheel inside Qt code. You have to tell them if that's a problem: qt-bugs@trolltech.com I believe that you misunderstand. The issue is *not* that buttons 4 and 5 control window scrolling-- that is perfectly acceptable. The issue is that KDE hard-codes which of button means up and which means down. The code in question is in kdebase/kcontrol/input/mouse.cpp. Please revert the changes to AssignedTo, Component, and Product that you made. Please don't readd me to the lists. I receive all bugs regardless of whether I'm in the Cc: list or not. Anyways, I do believe that the problem is in Qt, not in KDE code. I'll reassign and we'll see if anyone with more knowledge of the code has an answer. Subject: [PATCH] Fix for bug 62268 (please review) Hello, The attached patch fixes bug http://bugs.kde.org/show_bug.cgi?id=62268 for laptop users. The patch works fine for me. Ok to commit? Regards, Ravi Created an attachment (id=2680) 62268.diff Regarding the patch, it seems to add a control to flip the meaning of buttons 4 and 5, and names this control "Laptop style mouse". A more accurate name is "Reverse scroll polarity". This function has nothing to do with a laptop-- I was only giving my laptop's input device as an example. Furthermore, just because one has this kind of mouse doesn't necessarily mean that they want to flip buttons 4 and 5. I agree with you on the reason for naming it as you suggest. However, most users would simply ignore such a naming - sometimes we do have to cater to the lcd. Note that I changed it only for left-handed users, so it does not strictly allow for reversing scrolling polarity for all users. Subject: kdebase/kcontrol/input CVS commit by ravi: Allow changing the scrolling polarity for 5-button and wheel mice. This is very important for left-handed laptop users. CCMAIL: 62268-done@bugs.kde.org M +23 -3 kmousedlg.ui 1.18 M +38 -7 mouse.cpp 1.89 M +2 -0 mouse.h 1.36 |
Version: (using KDE KDE 3.1.3) Installed from: Debian testing/unstable Packages The mouse control makes an invalid assumption about the physical input device when is sees 5 buttons. Namely it assumes that buttons 4 and 5 correspond to a "wheel" with 4 being up and 5 being down. This is not necessarily the case, for example: (pointer) (-- button1 --) (-- button3 --) (button4) (button5) That is the physical layout of my laptop internal mouse (note that button3 is emulated). Inputs 4 and 5 are not a wheel, but rather actual buttons below the standard buttons. So who is to say how buttons 4 and 5 map to the meanings "scroll up" and "scroll down" in this case? Furthermore, I should be able to change the handedness of buttons 4 and 5 from the control panel just as I do buttons 1 and 3. But KDE is always hard-coding 4 as up and 5 as down. If it is impossible or too hard to get information about the physical input device, then at least the mouse control should have an advanced mode which lets users manually set the button mapping.