Version: (using KDE KDE 3.1.2) Installed from: Debian testing/unstable Packages OS: Linux I would really like to stress how far behind other window managers KDE is in this case. All other major window managers seem to support "any mouse button" as an option for various bindings. I hate to see KDE lacking in this usability area. With KDE, I was forced to use imwheel for the purpose of binding my 6 + 7th mouse button to do Workspace switching. Let's face it, this is something that the average KDE user should not have to do. Virtually every mouse sold today has at least 5 mouse buttons, and any sort of quality mouse tends to have at least 6. With the effort and work you guys have put into KDE, it is quite apparent that you genuinely care about usability on Linux compared to our evil nemesis, and this is a point of pressure on that front. Any mouse event that X supports, KDE should support as well... After all, shouldn't mouse support "just work"? Thanks!
*** This bug has been confirmed by popular vote. ***
This bug should be closed as INVALID or something similar because the support for > 3 buttons + wheel has to be part of Qt. Every low-level mouse event handling is done by Qt so that's the place to add it.
Qt knows about this ? what's status this request in qt4 ? it's a Qt problem but KDE must be aware too...
KDE must indeed be aware of this. Current multi-button support in KDE is quite lacking, actually. For example, I can not assign any mouse button I want, to any action I want. I can only use "keyboard shortcuts" to do almost all of the things I want. As well, the options I can choose under "Deskstop -> Window Behaviour -> Actions" are lacking. I can not choose most of the same options I can pick under "keyboard shortcuts". What if I want to use button 4 (my "mouse wheel up") on the title bar, to move a window to the previous workspace? What if I want to use the middle mouse button, on the title bar, to maximize the window size? What if I want to use button 7 anywhere on a window, to move it to the front, move it to the next screen, and give it focus? We are entering the era of _unlimited_ mouse button support in X.org and the Linux kernel. As of x.org's 6.8.2 upcoming release, 10+ button mice will be fully support in Linux with modern 2.6 kernels. People will be plugging these mice in, all of their buttons will be perfectly supported under X, but then told that it "doesn't work in KDE". This is unfortunate, as I see it. Other window managers (sawfish, enlighenment, etc) already support this out of the box. They've been ready for years. They've supported 7 mouse buttons for all of this time, but kwin has not. This is not a verbal onslaught aimed at anyone or anything. It is just statement of fact, being that KDE currently has very poor mouse button support. For starters, there should be no difference between using mouse buttons or keys in "keyboard shortcuts". That is, a user should be able to use mouse buttons or keyboard presses, whichever they choose. KDE should also expand the options provided for buttons/keypresses on differing parts of windows. "Window Behaviour -> Actions" should likely be revamped to allow for different items to have infinite actions. That is, the "titlebar and frame" actions should not be limited to three mouse buttons. Instead, one should be able to choose any event that X provides, be it keyboard combo or mouse press (or both!), and link that to an action. Actions should also be expanded, to provide many of the options under "keypresses". Yes, this sounds lengthy and haughty. It isn't meant to be so. It's meant to be a roadmap for something that I find to be severely lacking in KDE, but this doesn't mean that I find KDE's progress to be overly slow. ;) There have been vast and innumerable changes to KDE over the last few years, and I applaud them. I do think, however, that it's time to look at this one area. Especially with _unlimited_ evdev protocol, mouse button support coming down the pipe for the masses, in a matter of weeks.
Qt has to support more than three buttons if you want to be able to use all of them in any KDE/Qt application. Neither kwin nor anything in KDE can work around this Qt limitation so file a Qt bugreport if you need such a feature.
Your logic is flawed, since KDE/Qt already supports _five_ mouse buttons. Furthermore, this bug is an issue, since QT _will_ support more than five mouse buttons. KDE should take pre-emptive action to ensure that it will support an unlimited number of mouse buttons. Configuration changes need to be made, options added, and the entire "keyboard bindings" concept should be reworked. Throwing this bug report away, means it will just have to be re-submitted in a few months / weeks time. This makes little sense.
no, Qt does NOT support five buttons, it just supports a static number of buttons in its QMouseEvent system and _that_ is the problem. Furthermore mouse-buttons have nothing to do with "keyboard bindings". Also kwin is just one out of many applications that would need changes if it wants to support whatever extended API QT 4 provides. at the time Qt supports an unlimited number of buttons applications will have to be adapted. You can reopen this bugreport when the time has to come change kwin but right now there's no way to archieve this goal. Closing this as LATER now because there's no way to support more than three buttons in Qt 3.
Actually, Stefan, Qt does support 5-button mice: left, middle, right, wheel up, wheel down.
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. ----------------
What a lame excuse from TrollTech. Why not support only one mouse-button, Apple doesn't support more than that :P
Yes, it is a lame excuse, but QT4 does provide a method for KDE to support > 5 mouse buttons. Reopening this bug.
*** Bug 107375 has been marked as a duplicate of this bug. ***
Dupe of #34362?
Yes. *** This bug has been marked as a duplicate of 34362 ***