https://bugs.kde.org/show_bug.cgi?id=34362 --- Comment #29 from rickst29 2010-12-08 08:58:46 --- (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. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.