Launchpad has imported 41 comments from the remote bug at https://bugs.kde.org/show_bug.cgi?id=34362.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2001-11-01T16:55:20+00:00 Ehmke wrote: (*** This bug was imported into bugs.kde.org ***) Package: kcminput Version: 2.0 (using KDE 2.2.1 ) Severity: wishlist Installed from: compiled sources Compiler: gcc version 2.95.2 20000220 (Debian GNU/Linux) OS: Linux (i686) release 2.4.3 OS/Compiler notes: currently there is only support for 3 mouse buttons and the mouse-wheel. But many mice have more than 3 mouse buttons (e.g. ms intellimouse explorer) so it would be appropriate to let the user configure the additional buttons to do some window operations or to emulate keyboard shortcuts. I hadn't found a possibility to do this using the x-toolkit. There is only support for maximum 5 buttons and these "buttons" are used by a 3 button mouse with mouse wheel. (Submitted via bugs.kde.org) (Called from KBugReport dialog) Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/0 ------------------------------------------------------------------------ On 2002-12-26T09:41:47+00:00 Garen-3 wrote: The intellimouse (explorer, optical, ...) mice have 5 buttons, with two being on the side that default to being used for back/forward in IE, which many people (myself included) become accustomed to. Mozilla and Phoenix support this, it's the only thing preventing me from using Konq most of the time. :) Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/1 ------------------------------------------------------------------------ On 2003-03-15T13:36:59+00:00 Stephan Binner wrote: *** This bug has been marked as a duplicate of 48062 *** Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/2 ------------------------------------------------------------------------ On 2003-03-31T15:23:01+00:00 9-ellis wrote: This is different than bug# 48062, since 48062 has to do with "modifier" buttons (whatever those are supposed to be...), and this is just about recognizing a button as a normal key. Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/3 ------------------------------------------------------------------------ On 2004-12-01T20:13:23+00:00 Rudolf-kollien wrote: I'm wondering that this wish is very old (over three years?) and the status is still "new". Really it would be a great help if it would be possible to define how many buttons and or wheel a mouse has. And assigning some features to this buttons. I tried around with the mapkey-pointer feature of X but with no/less success. Assigning a "doubleclick"-event to a pointer seems to be impossible. Using new Logitech MX1000 Laser with 10 buttons :-) Yes, even the mouse wheel can be pressed down, left and right :-) Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/4 ------------------------------------------------------------------------ On 2005-04-01T14:22:33+00:00 L-lunak-5 wrote: *** Bug 71328 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/5 ------------------------------------------------------------------------ On 2005-06-19T18:10:38+00:00 Allergy wrote: Just bought an MX1000 some weeks ago. Indeed, the only way to make the extra buttons (including thumb buttons!) work is to use imwheel (or equivalent software) and remap them to some keyboard events. That's nice, working great and full of possibilities, but far from easy for new users. They would expect those buttons to work out of the box, IMHO. This seems to be a Qt limitation, and if the documentation is up to date on this subject, it still is in Qt 4 : http://doc.trolltech.com/4.0/qt.html#MouseButton-enum (I haven't looked at the source). Perhaps you, KDE folks, will be able to push TrollTech in the right direction ? Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/6 ------------------------------------------------------------------------ On 2005-07-23T04:32:33+00:00 Coolguyzak wrote: I am in the same boat concerning my new mx1000. It would be great to be able to configure this without needing to use a 3rd party app to configure the extra buttons. I would suggest putting configuration in the kcm mouse module, however-- users will not expect mouse configuration to be in a keyboard/keymap list. :) If it does turn out to be a limitation of qt, then it would be great to have a control module, or portion thereof, that will configure the imwheel (or other app) to remap the buttons. Until a solution is found, I guess I'll configure imwheel by hand. Thanks! Zak. Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/7 ------------------------------------------------------------------------ On 2005-10-16T06:06:29+00:00 Thiago Macieira wrote: *** Bug 72199 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/8 ------------------------------------------------------------------------ On 2005-10-16T06:07:56+00:00 Thiago Macieira wrote: Sorry people, but this is a Qt issue and has to be resolved by Trolltech. If/when Qt supports this, we have to reassign back to kdelibs so that our libraries are adapted. Or does Qt support it already? Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/9 ------------------------------------------------------------------------ On 2005-10-16T17:38:48+00:00 8pp-kde wrote: Pasting an email from TrollTech here: ---------------- Qt can only provide an API to 5 mouse buttons, as other windowing systems, i.e. Win32, do not support anything beyond L, R, M, X1 and X1 at this point. http://doc.trolltech.com/4.0/qt.html#MouseButton-enum KDE, and specifically KDE's window manager, could implement handling for more mouse buttons by reimplementing QWidget::x11Event() in a platform specific fashion. ---------------- Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/10 ------------------------------------------------------------------------ On 2005-10-16T17:45:04+00:00 8pp-kde wrote: TrollTech has already provided an example method for getting this to work, as shown above. I do know that many other window managers have supported > 5 mouse buttons for years.. most of those since 4.0 of X11R6 first came out. I don't know if putting pressure on TrollTech would help, I don't really buy their reason (Win32 limitations) as anything approaching valid. However, KDE users have been waiting for > 5 mouse button support for many a year. Is waiting for Trolltech to get off their collective asses the best of ideas? They've clearly stated that Win32 is their target, not Linux (with their comment above). So.... we should wait until a new version of Windows comes out, hoping it supports more than 5 events, then wait as the years pass, hoping that TrollTech will play catchup to that??? I don't really see KDE lagging behind by 10 years in the mouse usability arena, as a logical target for the KDE community. Am I missing something here? Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/11 ------------------------------------------------------------------------ On 2005-10-16T17:49:20+00:00 Thiago Macieira wrote: Reassigning back to kdelibs. Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/12 ------------------------------------------------------------------------ On 2006-06-27T20:31:46+00:00 Montana Harkin wrote: What is the status of this bug? Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/13 ------------------------------------------------------------------------ On 2006-06-27T21:02:56+00:00 8pp-kde wrote: Not sure what you mean by requesting the status. It's still unresolved, if that's what you mean... Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/14 ------------------------------------------------------------------------ On 2006-08-04T16:11:15+00:00 Metz81 wrote: *** Bug 94082 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/15 ------------------------------------------------------------------------ On 2006-08-04T16:31:11+00:00 Harden-n wrote: Hi Mom, Christopher's crew was finishing up when I took the kids to the Dojo this morning. It looked a lot better so I gave him the check. He said to call him back if there is anything else they forgot. Have a great day. Love you, Don ow...@bugs.kde.org wrote: [bugs.kde.org quoted mail] Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/16 ------------------------------------------------------------------------ On 2006-08-09T11:42:10+00:00 Hifi77 wrote: Is there any date, when this bug will be fixed? Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/17 ------------------------------------------------------------------------ On 2008-08-14T18:10:18+00:00 D wrote: I think this would be nice to have as well. Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/24 ------------------------------------------------------------------------ On 2008-09-16T20:20:40+00:00 Bkorb wrote: This would be very nice, but after two months of scrolling my screen whenever I press the "paste" button, I'd just be happy if I could get xev to see button 8 so I could remap it to button 2. This whole blasted mouse thing is a twisty maze of out of date and disconnected information. Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/25 ------------------------------------------------------------------------ On 2009-03-14T17:12:27+00:00 Msched wrote: I've also been missing this feature for years and was hoping it would show up in 4.x, especially with the various new switching effects which would be much more useful when mapped to mouse buttons. A useful workaround for now is xbindkeys, which can map at least some mouse buttons to custom keyboard shortcuts, but I really think KDE should allow us to configure mouse buttons just like any other keyboard shortcuts (after all, the keyboard configuration system is one of the great things about KDE). Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/26 ------------------------------------------------------------------------ On 2009-09-12T09:31:43+00:00 Smedvek wrote: Sorry to respond to an ancient bug, but this is an accesibility issue for some people. I have a very very limited example in that moving windows is rather inconvenient for me in kwin compared to how I move them in fluxbox, where I just have to say in my 'keys' file, how and where to handle any mouse buttons it finds. For example, I use: OnWindow Mouse9 :StartMoving Which lets me move windows around by clicking anywhere on them with mouse9 and moving around. Unless my titlebars are huge, it's physically frustrating to hit the titlebars (due to shakiness). I use 'stuck keys' to hold down alt while I move a window around if I have to, but I'm very happy being able to just use one button instead. (using something like btnx to map ALT and Mouse1 to Mouse9 just passes the ALT+Click through to the app right past the window manager) This was probably a wasted effort, I just wanted to be one more voice of 'me too' in favor of more comprehensive mouse support. Thanks. Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/27 ------------------------------------------------------------------------ On 2010-01-13T01:33:40+00:00 Michael Stather wrote: IMHO both mouse buttons 4 and 5 and also the "forward" and "backward" keys on some keyboards should be implemented out-of-the-box. A must in usability ;) Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/29 ------------------------------------------------------------------------ On 2010-02-02T19:03:07+00:00 Γεώργιος Γεωργάς wrote: A necessary feature for a modern desktop. Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/30 ------------------------------------------------------------------------ On 2010-06-06T21:21:26+00:00 murmlgrmpf wrote: I found this very same bug under the bug report numbers: 226370, 34362 and 227040. It is quite poor, that this usability bug has been consistently there for almost a decade despite the fact that it has rank 26 regarding the votes of all bug reports. There seems to be a hint for a solution pointed out by Trolltech. As stated above it is a nogo that KDE still remains the only platform on which extra mouse buttons do not work out of the box. Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/31 ------------------------------------------------------------------------ On 2010-06-24T02:26:49+00:00 Christoph-maxiom wrote: *** Bug 242645 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/32 ------------------------------------------------------------------------ On 2010-09-01T21:46:41+00:00 Juhani Åhman wrote: Qt bug list suggests that this issue will be fixed in Qt 4.7. http://bugreports.qt.nokia.com/browse/QTBUG-9214 http://bugreports.qt.nokia.com/browse/QTCREATORBUG-899 KDE just needs to implement support in Nautilus etc. Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/33 ------------------------------------------------------------------------ On 2010-09-01T21:59:52+00:00 Todd R wrote: As far as I can see those patches are implementing only back and forward buttons (not all additional mouse buttons) and only for the Qt Creator help browser. Rekonq has support at least for the back button, so it is possible in KDE. Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/34 ------------------------------------------------------------------------ On 2010-12-08T08:13:59+00:00 Rickstockton-7 wrote: (In reply to comment #26) > Qt bug list suggests that this issue will be fixed in Qt 4.7. > http://bugreports.qt.nokia.com/browse/QTBUG-9214 <<snip>> Todd is correct in his reply: the qt updates implement only two additional buttons (and the requirement seems to have been inspired by Firefox on mobile devices). I have been thinking, QUITE HARD, about the origins of the problem.... and how to solve it pretty easily for the "special case" of X11. Here's my essay - it's actually quite short. The authors of the qt-X11 mouse interface looked at the byte of mouse mapping buttons which X11 returns with a mouse event... and (apparently) chose to give the same bits to the user. A couple of bits are not used for button mapping, and so, obviously, there aren't enough bits returned in the bit-field to map all the buttons in a typical "gamer" mouse. HOWEVER: X11 easily supports additional mouse buttons, and the events ("mouse press" and "mouse release") which it emits to listening software specify those higher=numbered buttons! You Linux-X11 people with "big" mice can check this out, it's easy to see. First, to see what X11 has heard about, open any kind of terminal window within your KDE Session (a "kterm" does just fine) and run /usr/bin/xmodmap with the "-pp" command line option. ("-pp" asks xmodmap to display the current button mapping on $STDOUT.) Here's the response which I get for my mouse: rickst29@my3rdbox ~]$ xmodmap -pp There are 13 pointer buttons defined. Physical Button Button Code 1 1 2 2 3 3 4 4 5 5 6 6 7 7 8 8 9 9 10 10 11 11 12 12 13 13 [rickst29@my3rdbox ~]$ Yes, X11 understands that my mouse can emit events for 13 different numbered buttons. (NOT 3, or 5, or 7.) There is another program which you want to try out, so that you can *SEE* the X11 events: run "xev", move your mouse into the little test panel which the program creates, and start pressing/releasing *YOUR* buttons. You will find them all, and the printf() shows them by number. (Do take note... every bit of mouse motion creates another event, so you might want to pipe it into file, and edit the file afterward.) You usually **DON'T** have to create them via "keyboard emulation" tricks. evdev tries to get the number of mouse buttons dynamically, from HAL. In good Distros, the only need for an explicit usually (And eventually, it will be udev instead -- but if the X11 programmers are doing all the heavy lifting for us, qt and KDE should take advantage of their work on this platform.) Many of us know, already, that software built on GTK+ has no problems using these "extra" buttons. (I use compiz, instead of Plasma, to provide my compositing desktop within KDE -- just so that I can do neat things with all those buttons !!) The user doesn't have to configure weird keyboard emulation tricks, it just works. So, where did qt go wrong? They inspected the API, rather than handling button events directly. And the API only shows the bit mask, which everyone knows to be grossly inadequate. (Xorg developers discuss the need for a wider bit-mapped field in a future offering they label as "X12", it will provide for a mask of at least 32 buttons- maybe 64). But don't hold your breath, this won't happen for years. In the meantime, it seems like qt gets "dragged" into supporting just one or two more buttons every year or two, on the basis of some "critical" application requirement (e.g., Firefox). qt-X11 leads should, IMO, stop adding "more buttons" one or two at a time. If they re-do the API to support *ALL* of the buttons which the platform presents for a 2D pointer device, they'll prevent huge amounts of ongoing pain. In the case of X11, qt could easily run this specific query, and it should be re-worked to provide the press/release events which X11 is capable of emitting. This is an API change, of course, and could be done in several ways. All of these "gamer" mice, were built for MS-Windows first. qt on MS- Windows, and KDE on Windows, can support them with the same API, "hiding" the lower-level details inside the qt-to-platform runtime I/O interface. Now I have a question for Stephan, or any other KDE persons who might take ownership of this long-standing design defect. (de-facto in KDE, de-jure in qt.) Who takes the lead on creating a discussion of requirements for the implementation which KDE needs from qt? I'm not an idiot, but I've never worked within any "open software" community... I'd be better as a commentator and coder, not so good as a TEAM LEADER. Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/35 ------------------------------------------------------------------------ On 2010-12-08T08:58:46+00:00 Rickstockton-7 wrote: (In reply to comment #10) > Pasting an email from TrollTech here: > > ---------------- > Qt can only provide an API to 5 mouse buttons, as other windowing > systems, i.e. Win32, do not support anything beyond L, R, M, X1 and X1 > at this point. > > http://doc.trolltech.com/4.0/qt.html#MouseButton-enum > > KDE, and specifically KDE's window manager, could implement handling for > more mouse buttons by reimplementing QWidget::x11Event() in a platform > specific fashion. > ---------------- Old post, but let me snuff that claim from the qt respondent. (It was false then, and remains false now.) This claim that Windows cannot support "gaming" mice is, and was, pretty absurd. These mice were invented for Windows games first, and they're extra buttons are now used in huge numbers of programs on that platform. The same can be said for programs, Window Managers, DE's, and ToolKits based on GTK+. qt's enumeration doesn't support more buttons. (And neither does the X11 button state Byte; you need to follow the events and construct "wider" Table within "your own software". By which I mean qt software, of course ;) It is strategically preferable to work this out inside of qt, rather than KDE. First problem: Writing this low-level support into KDE on X11 would lead to another implementation for KDE on Windows, gumming up KDE with platform-specific code (in a fundamental conflict with the isolation from platform hardware code which we want to maintain). Second problem: Lots of qt platforms which might not need an entire Linux-based Desktop (Televisions, Refrigerators, etc.) might still have need for multi-button, 2D pointer devices within a qt-based GUI. Can you say "Meego"? Sure you can, and I'll bet that Intel agrees me on this. Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/36 ------------------------------------------------------------------------ On 2010-12-14T09:41:52+00:00 Rickstockton-7 wrote: status update. After a helpful discussion with some late-night qt Devs on their IRC channel, I have just opened a bug with qt -- and I intend to provide a functional, ready-for-review update for this "ancient" issue. (Both the code and the Doc.) No comments yet, not even extra info posted by me-- just the basic definition of the issue. http://bugreports.qt.nokia.com/browse/QTBUG-16092 Within X11, the "button" field of the typedef for XButtonPressedEvent and XButtonReleasedEvent is an unsigned int. *NOT* a bitmask, and the X11 mask field is limited to 5 bits. So, if a higher-numbered button is ALREADY in pressed State when the mouse enters your App Window, there's no way to advise you of that. We'll only be able to show a single button number for a "high-numbered" press or release which takes place within YOUR window, with masked state of buttons L, R, M, X1 and X1 (only!) provided in the too-small button mask field. Unsure whether I'll have to create a subclass to provide "extended" versions of the API. I'll SWAG that it will b necessary, for BC... there's just not enough bits left to play with. :(( Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/37 ------------------------------------------------------------------------ On 2011-05-12T00:52:14+00:00 Christoph-maxiom wrote: *** Bug 272728 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/38 ------------------------------------------------------------------------ On 2011-08-02T06:40:40+00:00 Rickstockton-7 wrote: The patch for qtbug 16092 caused broken BC, but I've got another way. And THAT project will not only give us all 32 possible buttons, it will also provide the full 32-bit ButtonStateMask ** whenever a user executes the 'READ' function **. So, you could check for concurrently pressed buttons when a MouseButtonDblClick Event is received... and make the combination of both invoke certain code as a special "shortcut", different from either oif those buttons alone. You would also be able to check for pressed ButtonStateMask buttons after receiving WHEEL events-- creating new shortcuts, or actions, for those combinations as well. (How about scroll up/scroll down + RIGHTBUTTON == zoom out, zoom in? Entirely on the mouse, without reaching for the keyboard at all. I can do it, at least on x11. Whther Qt wil accept it is another matter entirely. Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/39 ------------------------------------------------------------------------ On 2011-08-02T13:47:16+00:00 flying sheep wrote: sounds huge, good luck! Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/40 ------------------------------------------------------------------------ On 2011-11-15T00:10:16+00:00 Rickstockton-7 wrote: I'm happy to declare this bug RESOLVED by upstream changes, coming in Qt5. For reference, my Qt changeset was: http://codereview.qt- project.org/#change,8548,patchset=6 and the corresponding Qt BUGID was https://bugreports.qt.nokia.com//browse/QTBUG-22642. Because Qt5 will include support for up to 31 buttons, KWin (and other KDE programs) may use those buttons- if the user's platform and pointer device are recognized as "Gamer-Button Equipped" by Qt itself. Here is the new set of button names within qnamespace.h: enum MouseButton { NoButton = 0x00000000, LeftButton = 0x00000001, RightButton = 0x00000002, MidButton = 0x00000004, // ### Qt 5: remove me MiddleButton = MidButton, XButton1 = 0x00000008, BackButton = XButton1, ExtraButton1 = XButton1, XButton2 = 0x00000010, ForwardButton = XButton2, ExtraButton2 = XButton2, TaskButton = 0x00000020, ExtraButton3 = TaskButton, ExtraButton4 = 0x00000040, ExtraButton5 = 0x00000080, ExtraButton6 = 0x00000100, ExtraButton7 = 0x00000200, ExtraButton8 = 0x00000400, ExtraButton9 = 0x00000800, ExtraButton10 = 0x00001000, ExtraButton11 = 0x00002000, ExtraButton12 = 0x00004000, ExtraButton13 = 0x00008000, ExtraButton14 = 0x00010000, ExtraButton15 = 0x00020000, ExtraButton16 = 0x00040000, ExtraButton17 = 0x00080000, ExtraButton18 = 0x00100000, ExtraButton19 = 0x00200000, ExtraButton20 = 0x00400000, ExtraButton21 = 0x00800000, ExtraButton22 = 0x01000000, ExtraButton23 = 0x02000000, ExtraButton24 = 0x04000000, MaxMouseButton = ExtraButton24, }; Q_DECLARE_FLAGS(MouseButtons, MouseButton) You see several 'alias' names in this list. I advise the following usage: 1: Use 'MiddleButton' instead of 'MidButton'. 2: Use 'BackButton' and 'ForwardButton' -- these names are more widely accepted and used than the alternatives (Xbutton1, Xbutton2, ExtraButton1, ExtraButton2). 3. For all higher buttons, including the so-called 'TaskButton', use the 'ExtraButton_nn' name. And do remember: This is upcoming in Qt5 ONLY; it will NOT be made available in the Qt 4.x Release Series. Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/41 ------------------------------------------------------------------------ On 2011-11-15T00:18:37+00:00 Rickstockton-7 wrote: Before I request that this bug be closed (RESOLVED, UPSTREAM), I wish to thank Thiago Macieira -- who's patience made this enhancement possible. Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/42 ------------------------------------------------------------------------ On 2011-11-22T16:36:34+00:00 Rickstockton-7 wrote: Closed, by me, after making myself the assignee. This capability will be present in the near future, when KDE programs are running against Qt libraries at version 5.x. resolved/upstream. Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/43 ------------------------------------------------------------------------ On 2011-11-22T16:54:02+00:00 8pp-kde wrote: This is great news, but should this bug be closed? This bug is not just about getting the mouse buttons recognized. In fact, this was *already* possible with programs like imwheel and keyboard button mapping in KDE. The real point behind this bug is to make it very, very easy to have users assign these buttons in KDE to useful functions. That is, a button to change forward/backwards through your desktops, a button to move a window forward/backwards through desktops, a button to shade/unshade windows, and so on. As far as I know, this functionality is not in KDE as of yet. So, this bug should remain open I'd assume. (not faulting people for the enthusiasm, but the front end existing in KDE to configure this functionality is more than 1/2 of what this bug was about...) So, put again, how can upstream resolve a bug that has to do with KDE having a friendly GUI to incorporate extra buttons -> window manager operations? Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/44 ------------------------------------------------------------------------ On 2011-11-22T21:07:51+00:00 Michael Stather wrote: I also think this is not the solution but supporting more hardware buttons is part of another limitation. Let's imagine a user who has a mouse with "forward-backward" buttons on it and a keyboard also with forward an backward buttons. Neither of them work. Many other apps (browsers and e.g. the ubuntu software center) don't need special configuration for these keys, they just work. It would be also not appropriate to have to configure this, since the buttons have a strict meaning on them. The best thing would be just support all "special" buttons side-by-side to what you configured. I guess the scancodes are standardised. I don't want to be rude but I guess neither of the devs has a mouse or keyboard with "forward-back" buttons. Expecially for web browsing this is very very handy. And work for years...with windows...with gnome...with most webbrowsers...sadly not in kde apps :( Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/45 ------------------------------------------------------------------------ On 2011-11-22T23:07:42+00:00 Rickstockton-7 wrote: (In reply to comment #37) > This is great news, but should this bug be closed? This bug is not just about > getting the mouse buttons recognized. In fact, this was *already* possible > with programs like imwheel and keyboard button mapping in KDE. > > The real point behind this bug is to make it very, very easy to have users > assign these buttons in KDE to useful functions. Michael, KDE Bugzilla is "wide open" for comments, and many of these comments (including some which *I* made) ignore an important aspect of bug management procedure: ONE issue == ONE bug. ALWAYS. We have several other bugs which touch on "using the mouse", and I'm about to take ownership of (at least!) one of them. I will probably bisect those bugs even more, because nearly all of them involve more than one programming job, and because they're full of comments which ask for unrelated things. Here's an important one, with nearly as many votes as you saw here: https://bugs.kde.org/show_bug.cgi?id=48062. Please take a look. You'll see that the 'description' (the title) asks for one very specific thing, but nearly all of the comments (and even the attachment) are talking about something completely different. 48062 is about defining the mouse button to emulate a modifier key -- and ONLY a modifier key. On your keyboard, the modifiers- Shift, Ctrl, Alt, Meta, Num Lock.... do nothing by themselves. But nearly all of the comments talk about Actions-- which are typically invoked by a Modifier AND ANOTHER KEY, or (as the comments request) a mouse click. Using a high-numbered mouse button to perform an action (https://bugs.kde.org/show_bug.cgi?id=96431) involves much, MUCH simpler programming. But 48062 could be used to provide instant keyboard layout switching, modifiers which don't even exist on many keyboards (my USA-105 Keyboard has no pre-defined key for MOD3), and better usability for people with damaged hands. Exanding the shortcut system, to accept single or multiple mouse clicks as Events which invoke user-specified actions, is that 3rd bug, 96431. But this was pre-requisite for both of them: FIRST, we need to be notified of the button Events. That job is done (mostly.... I've still got coding to do on other Qt5 platforms, such as Wayland. I'll be crdating additional Qt bugs for tracking work in those modules). That's why this bug is closed. Your 'main point of the enhancement', and I strongly agree with you, is (https://bugs.kde.org/show_bug.cgi?id=96431). You may or may not be interested in 48062, which is a lot harder for me to accomplish- and that's exactly why I will start on that one sooner. (As happened with this bug, that solution would lie entirely within Qt.) If I didn't explain this well, feel free to come right back and ask me some more. OK? Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/46 ------------------------------------------------------------------------ On 2011-11-22T23:43:38+00:00 Rickstockton-7 wrote: (In reply to comment #38) > I also think this is not the solution but supporting more hardware buttons is > part of another limitation. > Let's imagine a user who has a mouse with "forward-backward" buttons on it and > a keyboard also with forward an backward buttons. Neither of them work. > Many other apps (browsers and e.g. the ubuntu software center) don't need > special configuration for these keys, they just work. It would be also not > appropriate to have to configure this, since the buttons have a strict meaning > on them. > The best thing would be just support all "special" buttons side-by-side to > what > you configured. I guess the scancodes are standardised. > I don't want to be rude but I guess neither of the devs has a mouse or > keyboard > with "forward-back" buttons. Hi, Michael! There are a lot of comments about this, but you don't need to read them all- I wasted MY time for you, so you get only the 'executive summary' ;) Here, among the KDE people, we strongly agree that 'BackButton' and 'ForwardButton' are widely recognized and used for those purposes. The current names, 'XButton1' and 'XButton2' are cryptic and non-obvious. So, if you look at the actual code in Comment 34, you see that I created new alias names for those buttons. Following the change to make the button identity obvious to other Developers, our process calls for bugs to be written against the specific programs- not the entire Kdelibs (or Qt, as it ultimately turned out to be.) Konqueror is one of those programs, obviously. File browsers- Krusader and Dolphin together with most any FileChooser pop-up (the code is shared) are another obvious candidate. And Amarok is another: Go "back" to the Previous Track or Scene in the album/movie. But I won't be writing that code- it gets managed within those specific projects. Different Product == Different Bug. BTW, my initial reason for doing this was "feature-parity" with GTK+ (the Qt-like library underneath Gnome-2) and the Compiz Window manager. I have had the EXACTLY the same opinion which you have, and our 1419 other voters. Since KDE 4.8is frozen for "new features in the API", you won't be seeing this in the near future. But KDE-Next, in 2012, will have it all. <joke > BTW, did you just offer to buy me a Razr Naga? If so, I prefer the "molten" look. My current mouse (Logitech 700) has only 14 buttons, and I'm including the 4 tilt wheel directions in that count. Need Razr! < /joke > Reply at: https://bugs.launchpad.net/kdelibs/+bug/62949/comments/47 ** Bug watch added: KDE Bug Tracking System #48062 https://bugs.kde.org/show_bug.cgi?id=48062 ** Bug watch added: KDE Bug Tracking System #96431 https://bugs.kde.org/show_bug.cgi?id=96431 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-system-tools in Ubuntu. https://bugs.launchpad.net/bugs/62949 Title: No way to configure mouse button number Status in kdelibs: Won't Fix Status in “gnome-control-center” package in Ubuntu: New Status in “gnome-system-tools” package in Ubuntu: Invalid Status in “kde4libs” package in Ubuntu: Won't Fix Bug description: Using kde-systemsettings, I can't configure my 6 button mouse. It would be interesting to just have a way to say "this mouse has X buttons". To manage notifications about this bug go to: https://bugs.launchpad.net/kdelibs/+bug/62949/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
