Re:Mouse Shortcuts (was: Qt 5.1 feature set and freeze date)
Executive summary: No, there will be no such project for Qt 5.1. And very likely, for Qt, never. On 02/13/2013 07:43 AM, Mark wrote: On Wed, Feb 13, 2013 at 9:49 AM, Knoll Lars lars.kn...@digia.com wrote: Hi everybody, I would like to start the feature freeze Qt 5.1 middle of March. big Snip Lars Finally, the components :) Now i hope that Rick (added to cc) manages to get the shortcut patch done in time. The patch as in allow mouse keys in shortcuts as well. I really hope so :) Mark, I've discussed my notions with Alan Alpert, and I accept his assessment: The LOC to write explicit mouse shortcuts into Apps, with NO new Classes in Qt, is nearly as small as it would be after adding a ton of code and API into Qt. And so, we should not put a ton of effort into mouse shortcuts at the Qt Level. The main issues which led me to this conclusion are: (1) There exist no standard button sequences, varying by platform, in the manner of standard key sequences. From an application level, I think that any differences between mouse shortcuts on platforms (Cocoa, Windows, KDE, Gnome) would be up to the specific program, or the platform environment. (Thus, the platform target, if one exists, is more likely KF5.x -- with published HIG for Developers of KDE Applications, and other DE HIG Developers, to see and perhaps copy as they please.) (2) Ultimately, shortcuts go to 'Actions'. AFAIK, you can't define a multi-keysequence 'QAction' in QML, so the concept of simply adding Mouse Sequences into a QML Action-Like element is a non-starter (at least, it's a non-starter for 5.1). Instead, your program goes directly from your MouseArea element to some sort of event handler code. (Which, in the behave like a mouse shortcut case, probably sends a signal to invoke a separate library or application function.) (3) A mouse doesn't have the Keyboard focus issues - focus moves with the mouse, you just need to define some big MouseArea elements to listen. (4) As you may remember, my favored objective is a combined shortcut scheme - in which a mouse event (click or double-cIick, with optional held buttons and held modifier keys), can work alone, OR it can also require a specific Key event (immediately afterwards). In the second case, the mouse event becomes a gate-keeper, opening the gate for a subsequent keyboard event. But that would get into keyboard focus issues, and add considerable difficulties. I REALLY don't know what I'm talking about - I understand the hardware, but not programming in Qt and KDE. One thing which we do have, recently added by Samuel Rodal and I, is a trustworthy tracking of State for ALL Mouse Buttons in the platform plugins. But above that level, I'm incompetent. When Qt 5.x has been enhanced to make QML -- C++ a bit easier, and we get our heads together for KF5.x, then we can work Global Shortcuts, and similar non-Qt features, at the KDE level. If those designs and implementations ultimately seem suitable for Qt, we can see about migrating them back to Qt. But right now, and for many months to come, I've got no specific implementation plans. In addition to waiting for related 5.2 features, I'm also inclined to let KF5 work through its' first Release - without loading it up with these difficult and uncertain new things. -- GPG fingerprint: 597E 4CE5 6D56 A7C2 DA3A 26FF F21F F828 0C86 165A
Re: Mouse Shortcuts
On 02/13/2013 12:01 PM, Mark wrote: On Wed, Feb 13, 2013 at 8:05 PM, Rick Stockton rickstock...@reno-computerhelp.com wrote: Executive summary: No, there will be no such project for Qt 5.1. And very likely, for Qt, never. On 02/13/2013 07:43 AM, Mark wrote: On Wed, Feb 13, 2013 at 9:49 AM, Knoll Lars lars.kn...@digia.com wrote: Hi everybody, I would like to start the feature freeze Qt 5.1 middle of March. big Snip Lars Finally, the components :) Now i hope that Rick (added to cc) manages to get the shortcut patch done in time. The patch as in allow mouse keys in shortcuts as well. I really hope so :) Mark, I've discussed my notions with Alan Alpert, and I accept his assessment: The LOC to write explicit mouse shortcuts into Apps, with NO new Classes in Qt, is nearly as small as it would be after adding a ton of code and API into Qt. And so, we should not put a ton of effort into mouse shortcuts at the Qt Level. The main issues which led me to this conclusion are: (1) There exist no standard button sequences, varying by platform, in the manner of standard key sequences. From an application level, I think that any differences between mouse shortcuts on platforms (Cocoa, Windows, KDE, Gnome) would be up to the specific program, or the platform environment. (Thus, the platform target, if one exists, is more likely KF5.x -- with published HIG for Developers of KDE Applications, and other DE HIG Developers, to see and perhaps copy as they please.) (2) Ultimately, shortcuts go to 'Actions'. AFAIK, you can't define a multi-keysequence 'QAction' in QML, so the concept of simply adding Mouse Sequences into a QML Action-Like element is a non-starter (at least, it's a non-starter for 5.1). Instead, your program goes directly from your MouseArea element to some sort of event handler code. (Which, in the behave like a mouse shortcut case, probably sends a signal to invoke a separate library or application function.) (3) A mouse doesn't have the Keyboard focus issues - focus moves with the mouse, you just need to define some big MouseArea elements to listen. (4) As you may remember, my favored objective is a combined shortcut scheme - in which a mouse event (click or double-cIick, with optional held buttons and held modifier keys), can work alone, OR it can also require a specific Key event (immediately afterwards). In the second case, the mouse event becomes a gate-keeper, opening the gate for a subsequent keyboard event. But that would get into keyboard focus issues, and add considerable difficulties. I REALLY don't know what I'm talking about - I understand the hardware, but not programming in Qt and KDE. One thing which we do have, recently added by Samuel Rodal and I, is a trustworthy tracking of State for ALL Mouse Buttons in the platform plugins. But above that level, I'm incompetent. When Qt 5.x has been enhanced to make QML -- C++ a bit easier, and we get our heads together for KF5.x, then we can work Global Shortcuts, and similar non-Qt features, at the KDE level. If those designs and implementations ultimately seem suitable for Qt, we can see about migrating them back to Qt. But right now, and for many months to come, I've got no specific implementation plans. In addition to waiting for related 5.2 features, I'm also inclined to let KF5 work through its' first Release - without loading it up with these difficult and uncertain new things. Hi Rick, Ahh, bummer. No sequences with mouse keys in them. I would have really liked those and it would be very convenient in cases where i can user a CTRL + Mousekey combination.. I guess i just have to hack those together in my apps and put them on my blog then ;) Don't forget - a Ctrl + Mouse(ClickButton) + Mouse(HeldButtons) is all one event; it doesn't have the difficulties of an emacs-style shortcut. (I.e., multiple key events, one after another.) Classes for widgets-only is one case, widgets+QML seems to be quite different (at this time). I really appreciate your long standing work in this area and some of the code you've send me a while ago. I just hope that someone else knowledgeable in this area could step up and continue this effort. Cheers, Mark Thanks for those kind words, and understanding of my limitations.
Re: Does KDE Desktop want a full-width mouse/pointer Button State mask?
On 07/10/2012 07:17 AM, Rick Stockton wrote: It's awfully late for an API change to Qt5, but this would be an awkward Backward Compatibility problem to attempt in later Qt5 Releases: Should Qt5 present a 32-bit Button State mask? Oops, that's WRONG. My initial 32 mouse buttons updates already created 32 bit mask fields, because all of the Plugin, QPA and Mouse Button Event instances of Button Mask data are defined as Qt::MouseButtons datatype. The changes to copy ALL button State bits can therefore wait until a later 5.x Release (5.1, or whatever). But my main question 'Does KDE want this capability?' remains open. Please advise!
Does KDE Desktop want a full-width mouse/pointer Button State mask?
It's awfully late for an API change to Qt5, but this would be an awkward Backward Compatibility problem to attempt in later Qt5 Releases: Should Qt5 present a 32-bit Button State mask? ** Background ** As you all remember, I added more mouse buttons for MouseButtonPress and MouseButtonRelease events into Qt5 between December and March. The number of buttons varies according to the Platform Plugin, which (IIRC, SWAG) is as follows: Wayland, XCB using X11's evdev driver, OS-X Cocoa: 16 buttons maximum QNX: 8 buttons Windows: 5 buttons (i.e., no change from Qt 4.x). XCB using legacy driver mouse: 27 buttons DirectFB: supports up to 27 buttons within Qt, but DirectFB issues appear to limit mouse support to 3 buttons. And finally, IIRC, a MouseArea can only supports 5 buttons. ** Why this might be useful ** (1) Mouse/Pointer Shortcuts with 2 or more buttons, containing more than ONE button with a higher enum value than MiddleButton. (We already get a narrow mask containing Qt::LeftButton+Qt::RightButton+QtMiddleButton. But LeftButton might be used for gestures; RightButton pops up context menus, and MiddleButton is physically hard to push.) (2) Various KDE and Qt Application might want to determine the State of all buttons at various times (in particular, at the time of the first MouseButton event following an XCB_ENTER_WINDOW event.) ** Why it just became possible ** XCB Platform Plugin has been modified to use XI Version 2.x by default, instead of XI 1.x. XI V2.x provides a button mask of 32 bits. (Theoretically, multiple mask segments of 32 bits each. But we don't support those buttons, so we'll ignore any such extra bytes of mask bits.) Right now, in the platform plugin, we downgrade the XI 2.x pointer ButtonPress and ButtonRelease events, translating them into XI V1 events (losing information by doing that, obviously.) We SHOULD, IMO, break BC right now and include a 32-bit mask field for ButtonPress and ButtonRelease events on all platforms. That field will never contain a set bit for a button higher than the supported maximum button number for the platform being used, but will otherwise include all buttons which remain in IsPressed State at the time of of the event (excluding the button which caused a MouseButtonRelease event to occur).
Re: Re: Package Dependcies List on Techbase
Please excuse the Top-Post, my suggestion is VERY short: The terminology Optional Dependency sounds like a good term for these situations. (At least to me, a native 'en-us' person.) On 05/08/2012 06:18 AM, David Jarvie wrote: On Tue, May 8, 2012 1:07 pm, Allen Winter wrote: On Tuesday 08 May 2012 6:55:01 AM David Jarvie wrote: On Mon, May 7, 2012 4:36 pm, Allen Winter wrote: Howdy, I started putting the list of package dependences (arranged by module) onto Techbase. http://techbase.kde.org/Getting_Started/Build/Requirements The tables on the subpages there are generated by a perl program I wrote. That program reads the CMakeLists.txt files inside a module and generates wiki content I then copy+paste into Techbase. Please review for accuracy. 2) Is QtDeclarative actually REQUIRED for kdepim? Isn't it only required in order to build mobile apps? If so, it should be marked as Optional. Are there any other dependencies which are similarly marked as Required, when in fact they are optional? Well, I'm not planning to write a CMakeLists.txt parser. So I'm not planning to handle CMake conditionals. But I can add hacks as needed. In the case of QtDeclarative, the comment says that it is needed for Mobile. Making sure we have useful comments and descriptions can certainly help too. Yes, the comment says that it is for mobile, but Required is a strong term, and I don't think the comment in its current form makes it clear enough that Required might not actually mean what it says. In this particular example, QtDeclarative will not be needed for someone building for the desktop. This will be the default build option for many people, so I think it needs to be stated more explicitly that Required may actually mean Optional. I can appreciate that you may not have time to write a parser for cmake conditionals. But if conditional dependencies are going to be listed as Required, I think there should be a clear statement at the top of the page that Required doesn't necessarily mean what it says, and may mean optional, depending on what conditional settings are used.
Re: Shortcuts (WAS: [Development] api changes)
The main text of my reply is at the bottom ...
On 04/16/2012 05:15 AM, Michael Jansen wrote:
On Sunday, April 15, 2012 08:40:38 PM Thiago Macieira wrote:
On segunda-feira, 16 de abril de 2012 01.33.31, Stephen Kelly wrote:
The only applications that should do that are the workspace fixture
ones:
kwin and plasma.
Yes, those are the ones that were brought up, together with the
KWindowSystem class. Apart from those I don't think KDE uses X11, but even
KWindowSystem might be partially obsoleted by QPA (there is a task to
figure that out, but no one has taken it up yet).
Managing windows is a task only for the workspace applications. Putting
those classes in a generic library is a mistake.
I disagree. Things such as Window Position, Size, and the need to Move
a Window (to expose a UI keyboard) may also be fundamental for
Applications on Handheld Platforms (as being described in another
Thread). Keep it simple - that particular application needs to avoid
COMPLETELY hiding it's virtual keyboard, the requirement is
straightforward - so let's provide the Application-Level tools to do so
where we can. Where we can't, do it, note that in Doco (As GTK/Gnome has
done.) GTK seems to agree with me; all of these items ARE available in
the GtkWindow interface:
http://developer.gnome.org/gtk3/3.4/GtkWindow.html#gtk-window-get-position
http://developer.gnome.org/gtk3/3.4/GtkWindow.html#gtk-window-get-size
http://developer.gnome.org/gtk3/3.4/GtkWindow.html#gtk-window-move
http://developer.gnome.org/gtk3/3.4/GtkWindow.html#gtk-window-get-screen
and their corresponding setters, and a lot of other GtkWindow()
functions in 3.4.
I noticed, however, that the Gnome/Gtk people have a lot of complaints
about DPI. Apparently, the value which QX11Info provides isn't
trustworthy for screens with sizes other than 96 DPI. I wish that I had
a monitor with more than 96 DPI, but I don't so I can't see any
problems relating to this value.
QX11Info is used in many places (including some widgets), and perhaps some
places where it shouldn't be used, but it's still a porting burden even to
figure out how to port the stuff (It's not clear to me how to, and the
changes file doesn't even note that the class is removed).
kf5{frameworks}$ grep -roh QX11Info::[^\)]*) * | sort | uniq
QX11Info::appDpiX( int )
QX11Info::appDpiY( int )
QX11Info::appRootWindow()
QX11Info::appRootWindow( screen_P )
QX11Info::appScreen()
QX11Info::appTime()
QX11Info::appUserTime()
QX11Info::display()
QX11Info::screen()
QX11Info::setAppDpiX(0, 96)
QX11Info::setAppDpiY(0, 96)
QX11Info::setAppTime(time)
QX11Info::setAppTime(timestamp)
QX11Info::setAppUserTime(time)
QX11Info::setAppUserTime(timestamp)
Porting required for some of them, others need refactoring.
I have one thing to add where we probably need some support from the qt
project to do it correctly. Global Shortcuts.
Since Qt does not support them we have to implement them ourselves. Which
means working with X11 KeyCodes. Because there are no exporteded Qt Functions
that map between X11 KeyCodes and Qt KeyCodes we had to implement the mapping
ourselves (KKeyServer iirc) but failed to do that correctly because the code
in question is complex. A source of many kde bugs.
All that descibes Qt4. No idea what changed in Qt5.
But such function or some Qt support for global shortcuts would help us.
The same applies afaik for the mac. No idea about windows.
I would be delighted to help with the job of pushing KDE 'Golbal
Shortcuts' Upstream (into a 'Global Shortcuts' property manager within
Qt). Rather than figure out keyboard layout issues twice (once in Qt for
normal input and Qt's limited shortcuts, a SECOND TIME in KDE for
Global Shortcuts), do it all in Qt. As you know, Qt already has some
default keyboard shortcuts values. (Intra-program, loaded for each
program which includes the relevant headers.) But, for KDE's purposes,
this would need to be extended: Many 'Global Shortcuts' should be pushed
up to the Window Manager immediately, and the shortcuts need to be read
from some sort of properties file, rather than C++ headers.
We should, I think, provide shortcuts, (KWin Global, Intra-Application
Global, and Application-Specific) for mouse gestures and all those
new mouse buttons. (KDE has an all-time-top-10-voted-for Bug on this,
IIRC). And a simple, coherent shortcut-override system should be in
place for any/all of those input devices. But I need some leaders... I'm
pretty useless as a designer or programmer.
Re: Re: Shortcuts (WAS: [Development] api changes)
On 04/16/2012 01:53 PM, Thomas Lübking wrote: Not much idea about the context, but Context was handheld- where Qt wants to be capable. Managing windows is a task only for the workspace applications. Putting those classes in a generic library is a mistake. Am 16.04.2012, 21:25 Uhr, schrieb Rick Stockton rickstock...@reno-computerhelp.com: I disagree. Things such as Window Position, Size, and the need to Move a Window (to expose a UI keyboard) may also be fundamental for Applications on Handheld Platforms (as being described in another ... GTK seems to agree with me; all of these items ARE available in the GtkWindow interface: http://developer.gnome.org/gtk3/3.4/GtkWindow.html#gtk-window-move The function does NOT allow to move a window directly but asks the WM to do so. Everything else is highly error prone because the client will usually not know about the context (eg. pa. handhelds will often have fullscreen WM, but you also maybe in a tiling environment or the window is in a particular state that forbids being moveResized) or maybe fail on the condition (user currently moves windows around) application needs to avoid COMPLETELY hiding it's virtual keyboard ideally such would be achieved by a hint on the window (eg. the type, keep_above state) or using struts instead of managing the window by the client - i guess this discussion pointed wayland but eg. at least on X11 you easily get yourself into trouble if your start playing on the stacking order against the WM (therefore there's a restack request as well, and kwin even supports it since about ... some rather short time ;-) Cheers, Thomas I know that such a request is only an optional suggestion to the WM. Now, looking ahead: Do we want KWin (and maybe PLasma, as well) to continue skip layers, going directly to xcb or wayland (or ??) in the same way we currently do a lot of X11 queries and commands directly? If so, then, I'll be less concerned about the API which Qt 5.x provides for KDE use.
Shortcuts via Mouse Buttons, etc.
Partly in reply to Albert Astals Cid and Thomas Zander, on the KDE list (December 26): I am aware of the timing requirement (But Thomas- thanks for the reminder, in case I HADN'T been.) Since I'm the person who will write the code and doco, I HAVE TO have an idea how to make it work ;) I've looked at some existing code, and I see two ways to get this done. One is a variation of my original thinking, and comes from the inventor of Qt Shortcuts and KeySequence management. The other suggestion, also from one of the greatest Qt experts, is quite unexpected, and looks plausible too: (Alt 1) Slightly higher risk of falling on my face, but better integration: Create a QInputSequence Class (The current QKeySequence class would exist as a keyboard-only instance within the new, larger class.) An input sequence could include keys which are simultaneous with a mouse button State (the full State of all buttons, not just the XI 1.0 mask of Buttons 1-5). And ultimately, InputSequence could support events from other devices as well. (Alt 2) A shockingly easy kludge to write, but less ensible in concept: Just derive one (at most, two) new Classes from QGesture. Right now (4.8) we have QSwipeGesture, QTapGesture, and so on ... which are invoked, on a traditional Desktop, with one mouse button in pressed State. I could add QMouseButtonGesture, or extend Swipes and Taps to have Button State properties. Just about everything above is already built! But... is it just too weird for me to give people the option of handling buttonpress, buttonclick, and buttondoublelick (with single AND multiple buttons buttons) via 'gestures', as an alternative to the normal 're-implement Widgit Mouse Event handlers' and scene-based mouse programming schemes which we all use now? Approach #1 stays focused on Shortcuts, AND allows for future device classes to be added via 'Copy and Paste a device instance, then modify'. But my scheme for #2 would also give us the ability to create multiple instances of Gestures from the same motion (e.g., horizontal swipe), differentiated by button number. That's a pretty powerful upgrade too. Your votes? I'm favoring #1, even though it's possibly a bit harder, because #2 is so strange. And #1 can have a 5.x upgrade to add the TV remote control, or whatever, while #2 is pretty much stuck with gesture input ONLY.
Forum Discussion Page for 'mouse shortcuts'
Thomas, Todd, and Albert: this is pointed at you guys for suggestions. Thiago, it's mostly FYI at this point. Final design and subsequent coding in Qt, starting in about a week. I have created a Qt Devnet forum Thread for work on Mouse Shortcuts. It's at http://developer.qt.nokia.com/forums/viewthread/12843 Right now, it's only got my initial post, which proposed code based on the same scheme as keyboard shortcuts (QKeySequence, QshortcutEvent, and QShortcut working with Qt signals and slots.) In my SIMPLE design, there will be 3 ways to invoke a mouse-based shortcut: mouse button click, button doubleclick, or holding one button down while clicking a second. You will not be able to mix keyboard keypress events and mouse button events together as a shortcut invocation sequence. (Invocations will consist of QKeySequence sets on the keyboard, OR mouse button actions -- not the two together.) Although, of course, you will be able to execute the same shortcut Action by performing alternative invocation sequences on the two devices. The 'Back' Shortcut Action, for example, will be invoked by either 'Alt + left' on the keyboard, OR the back button on the mouse. (Both as Qt-provided defaults.) I probably don't understand misunderstand Todd's current thoughts it -- because Todd speaks of handling multiple Devices at a very low level. With Qt5 platform plugins, nearly all Devices have really simple, high-efficiency input Event handling, so maybe you'd want to move the DBus interface upwards (maybe into QShortcutEvent, or QShortcut itself). But I'm not going to even try: If I were to propose messing with Shortcuts in the platform plugins, in a heavyweight way, the response would likely be a very firm absolutely not acceptable, in any form. Todd, if my GUESS is BAD, please correct me here on the ML - and I will post your correction (with no edits) into the working forum pages.
More devices into the Shortcut system...
It is time for us to Fish, or Cut Byte on two alternative ways to introduce Mouse-Oriented Shortcuts into Qt5 and KDE-Next: Todd RME has been suggesting a new design- oriented around DBUS. Unfortunately, I don't know how to do that coding. Todd, if your design gets a more favorable review from THIS group, within the next few days, I'll try to assist you in your work (as best as I can; I'm definitely not the brightest person here.) As an alternative, I'm suggesting the idea of enhancing one or two of the existing classes: I'd prefer to enhance the current QShortCutEvent and QShortCut scheme, so that they can include Mouse Button events within a QKeySequence. (This will including the possibility of _only_ one or more Mouse Buttons, with no keyboard event at all.) If that proves difficult, I could create new Classes to do this-- but I think I can use the 'hasExtendedInfo' trick which one of the smart Qt guys has used to handle a variety of Signatures in the QtMouseEvent() code. I can work with *this* stuff on my own. Please give opinions soon, as we have only 3-5 weeks before the Qt5 API goes into soft freeze. After we have Mouse Buttons done, the same design could be extended to handle other input devices (joystick, multitouch, and so on.)
Is BugID 48062 worth all this?
I need advice- do the masters of KDE consider https://bugs.kde.org/show_bug.cgi?id=48062 to be important? It's got a ton of votes, but I'll SWAG that a majority opf those votes were really votes for https://bugs.kde.org/show_bug.cgi?id=96431 -- get higher-numbered mouse buttons into the shortcut system. Most of the comments in 48062 are actually about that subject, as is the attachment (perform the Alt-L action when a mouse button is pressed.) This is only about mouse buttons replacing modifier keys, you' still have to press something ELSE to get a keypress with modifier Event. And, it will be messy to obtain and maintain a miniaturize mouse button State mask structure for this, within Qt; I might have to require users to re-Press, and then hold, the modifier button which they are trying to invoke for the next keystroke (And fail to emulate in the case of entering the Window with the a modifier Button _already_ within pressed State. Remember- I only have 5 Mouse Button State bits in the Xi Version 1 Events, anything more I'll after to acquire (or build) on my own. And since Button 1 is already doing Gestures; and Button 3 is already doing Context Menu (or other things); and Button4/Button5 don't behave as actual buttons-- the only lower-numbered button which remains 'more-or-less-free-to-use, without problems' is MiddleButton -- and on a lot of hardware, MidddleButton is really, REALLY hard to press. So I think that the feature is useless, unless we support high-numbered buttons as the modifier keys. If you guys vote yes, it's useful then I'll try to ping the current bug owner, who hasn't made a 'comment' appearance in quite a while recently. I'll ask the current assignee if I can take it, and try to get it done within Qt. (That's the appropriate level of the software stack for this kind of Event Translation code.) If you guys vote No, more confusing than useful, and it looks really difficult to do then let's reject it. With the explanation that it's an overly specialized, and technically difficult, case of shortcuts- with a better approach defined by bug 96431. Not an exact duplicate, but with the users' needs more fully met by spending our time with that RFE instead. I watch the list for votes. Email works, too ;)
I have ALL MOUSE BUTTONS WORKING for xcb and xlib :)) on qt5
My thanks to you, MGrasslin, Aaron, Todd rme, and Thiago for coaching me towards this achievement. The new code is small, and VERY simple. We have no API changes (at least, not yet--- we should implement a mouse button mask "getter" as a new feature, but that's for later in the 5.x series. It won't have any BC issues.) I will need to write doco of the new Qt::MouseButton values, and others will need to translate that material. My "qt5_MouseButtonTester" is a QTextEdit window, with Mouse events (Click/Release/DoubleClick) extended to show some qDebug() on the parent console. Basically, it's an "xev" program for Mouse Buttons in Qt. This tester, on Qt::MouseButton events, translates the button value back into the raw X11 number. I verified the button locations on my mouse to be correct, using xev itself. My mouse has "only" 14 buttons, plus the tilt wheel, for a total of 18. I know that the Razr 'Naga' has even more, but it's too small for my hand. (And the one I've got cost me enough money, already.) The logic works for up to 31 "button numbers", with 4-7 taken for the four possible directions of wheel motion. Just for fun, here's my output from clicking the buttons in order. I did perform a few DoubleClick events during the test: rick@x2:~/qt_projects/qt5_MouseButtonTester qt5_MouseButtonTester No platform plugin argument was specified, defaulting to "xcb". Successfully connected to display :0 Information of screen 346: width.: 1920 height: 1200 depth.: 24 white pixel...: ff black pixel...: 0 Running window manager: KWin MousePress: button 1 MouseRelease: MousePress: button 2 MouseRelease: MousePress: button 3 Mouse Wheel Event: UP Mouse Wheel Event: DOWN Mouse Wheel Event: LEFT Mouse Wheel Event: RIGHT MousePress: button 8 MouseRelease: MousePress: button 9 MouseRelease: Mouse DoubleClick: MousePress: button 10 MouseRelease: MousePress: button 11 MouseRelease: Mouse DoubleClick: MousePress: button 12 MouseRelease: MousePress: button 13 MouseRelease: Mouse DoubleClick: MousePress: button 14 MouseRelease: rick@x2:~/qt_projects/qt5_MouseButtonTester xlib runs the same, as far as my mouse buttons are concerned. But the App Window fails to repaint when I move it, or when I resize it. I'll SWAG that we've got an issue there, not the fault of kwin 4.6.5. (I can try running it from another User in which my desktop is fresh kwin 4.8-pre from GIT, if you think that the WM should be getting the blame for this behavior. Let me know on that, thanks. - - - - - FILES CHANGED: qnamespace.h: (The expanded enum/flags is prerequisite for all other code changes). DOCO IS NEEDED, I can write it in En-US. qguiapplication.cpp: (This contains a redundant check on button numbers being passed up from plugins. I made a one-line change, upping the high-limit to be 'Qt::Button31'.) qxlibwindow.cpp, qxcbwindow: (I added cases to the ev-button 'switch' block, for all of the new buttons. In this file, and qxcbwindow.cpp, I also eliminated an unnecessary multiply in the calculation of 'delta' -- simply setting values 120 : -120 as the hard-coded results of the "?" operator (rather than multiplying 120 * ? 1: -1). Should we do them all as one update, or do xlib first -- and add the more widely used xcb as a separate update, after the first one is found NOT to cause regression test failures over the next weekend? (BTW, I don't know how to do the Git Clone and Request procedure, and I'm a slow learner-- it would REALLY be better if I simply emailed these files to you.) Changes are public domain, of course - I think that I've already certified acceptance of the Qt license exceptions for my Contributions. - - - - - - - Now, for Wayland: I can create alternate UserIDs on my PC, of course. But the plugin fails to compile, issuing the following message: . -o qwaylandinputdevice.o qwaylandinputdevice.cpp qwaylandinputdevice.cpp:527:1: error: too many initializers for const wl_input_device_listener make: *** [qwaylandinputdevice.o] Error 1 Not a missing library or header, my hand-edit of the Makefile was correct. I suspect that this results from my use of a fresh 'Pull' of Wayland, per the README instructions. I don't have time for this one (and I'm a slow learner), can you or another 'Grandmaster' take care of it?
Just kwin, or do the whole thing?
A kde-core post as well, because I'm offering to resurrect the Dead. ;) Looking ahead, it's going to be awkward mixing Qt names for Buttons = XButton2, while using X11 names for higher numbers. I'm new to C++, but pretty solid on everything except polymorphism and certain asepcts of inheritance. Should we create our own 32-bit-wide Button State field, and enumeration of 'Higher-Button' names, as an extension of Qt's MouseEvent? There's not enough time (before code freeze) for me to write, and test, such an extended MouseEvent Class on the *ENTIRE* set of plugins which exist in Qt 4.x -- but I could do that job for an extremely limited number of plugins and higher-level interface Classes. That would give you and me, (and all other KApplication programmers) the full set of buttons. Some X11 big-shots (Peter H, Daniel Stone) have advised me that they anticipate no problem in mixing Query State versus Event State in the way I'd be doing it - as a separate function call, not automatically done with every mouse event. This would provide the 'not limited to just kwin only' feature which we, and a couple thousand KDE bug voters, have wanted for about 10 years. It becomes a ongoing maintenance issue for qt-copy, and/or kde-core :( I'd be DELIGHTED to volunteer as THE MAINTAINER of such code -- but I'm limited to the Linux platform. (I've got no Windoze compiler, or Windoze input driver API competence, or even a Windoze computer.) If you can identify which plugins (xcb, glib, ) we would need, and if they turn out to be VERY few in number, then I could probably attack and kill the ENTIRE shark within the next two weeks- instead of limiting us to Workspace Window Actions and compositing Effects. In the longer term, there's probably another need for this, WRT Wayland: On the input side, Wayland 1.0 is a quick-and-dirty project with no intention of supporting input pointer devices in a complete manner. They anticipate an aggressive schedule for Wayland V2 -- but if Qt intends the Qt5 API to last virtually forever, with binary BC, then Qt users are probably stuck with the limitation sof Wayland V 1.x for a long time. (Features such as: multiple pointers on the same App window, 3d pointers, and so on could only be done with the kind of messy BC tricks which I'm proposing to provide more buttons here.) The last time I looked at Wayland (August), they had support for only 3 buttons. Two questions: (1) If you 'masters of KDE' would like me to cancel the kwin-only project and jump into the bigger 'Shark Tank' (with an actual KDE place to put the resulting classes), please advise which qt4 plugins would be needed. (Remember, I CAN'T DO THEM ALL, there are too many for this time frame.) And where the module would go (qt-copy, or kde-core, or some add-ons library ???). The Qt code which I showed in last night's post is unchanged from Qt4 to Qt5, so I'll SWAG that those plugins which survive into Qt5 on the traditional graphics stack (as X11, non-Wayland platform input support) are virtually unchanged as well. I could be wrong, of course. I have NO IDEA what Nokia's upcoming Beta versions might have. For Kwin only (follow-up with Martin): (2) elseif kwin-only: Then how/where to define the enumeration of buttons above XButton2 (Button 9). My scheme, using only the first 3 buttons as modifiers, completely avoids the issue of a full-width Button State mask, because we'd only be using the button number, event type, and skinny State Byte which we have already. Am I correct in assuming that I should I execute effects and actions in the Qt way (i.e., on button RELEASE, rather than Button Press)? Are there any exceptions? Thanks for everything! Real Life will keep me away from that XButton1, XButton2 mis-identified' Update until this evening (USA), but it should be there before tomorrow.
gamer mouse button shortcuts (LONG)
I've been inspired by the 'shortcut doc' Thread on kwin ML. This concerns mouse devices with extra buttons driving our desktop, and creating mouse-based shortcuts. SAD STORY You may recall that, many months ago, I was encouraged to try a Qt enhancement for this. Qt consumes X11 ButtonPress and ButtonRelease events for X11 button numbers greater than 9, doing nothing with them -- and NOT passing them up to the Window Manager when a programmer tells Qt to pass along the Button Events I didn't use. After a couple of 'false' starts, I had a design which could preserve binary BC; but it did not meet the time frame for the end of of Qt4 series, and I have been unable to obtain a contact a 'coach' about Qt input programming anyway / SAD STORY Back then, Aaron also gave a tentative thumbs up! to my fallback proposal: If we can't fix Qt to 'handle' ButtonPress and ButtonRelease events for the buttons which are greater than 9 (the Events can show a button as high as #31), we can still create some pretty amazing shortcut capabilities in kwin -- before QT-based Apps even have a chance to flush the events down the toilet. That is, *IF* you masters of Kwin and the KDE Workspace are willing to help me mess around with it. My Goal is to define new shortcut output commands as needed, to be at least as feature-rich as Compiz. We can provide vastly more usability, actually, by adding the the mouse button modifiers trick into the project. I know that the timeframe is short. I therefore suggest that we restrict these mouse-based shortcuts to the land of kwin 'global' and kwin-controlled window-specific rules. GUI PROPOSAL: *PART 1* Re-do our KCM module for desktop effects, using CCSM as a guide to the GUI implementation. (BTW, CCSM == CompizConfigSettingsManager. If you're not familiar with Compiz, you can play around with it in most Distros by running compiz --replace from a Konsole. You'll still be running KDE, and the only breakage I've noticed in my Distro, Mageia-1, occurs in the Panel: the KDE Panel desktop pager shows Compiz desktops, but Compiz uses virtual desktops to implement our scheme of desktops. Their design has two layers of Desktops, while we use only one. My panel pager contains only one desktop, because I'm doing all of my switching and cube-spinning is done among the more numerous virtual desktops.) In CCSM, each setting has TWO lines for defining the user's choice of input. We have only the wrench button to view/change the keyboard sequence which invokes the change (with the info button following the wrench button). Their first line implements keyboard shortcuts, almost exactly as our wrench. But their second line, with a mouse icon, implements a choice of buttons (with modifier keys) to execute the same effect. Even though the extra line take up more screen Real Estate,I like their scheme, because it separates the logic for both the user and the programmer: The keyboard shortcut, and whether it has been changed, or whether it is even enabled, is completely separate from the mouse shortcut. The row is associated with one kind of shortcut and one kind of input device, not two.) Can someone please join in this, to handle CCSM? BTW, I don't know the proper way to encode hand-off of a mouse-shortcut keyboard sequence (containing mutiple keystrokes) to a Window. *PART 2* Modify the Compiz mouse scheme to ALSO allow the buttons within the XI Version 1 mask (Raw Buttons 1-3, Left and Middle and Right) to function as 'modifier keys' for other buttons. (This is my best idea: it gives a mouse user with limited numbers of buttons a whole slew of additional virtual buttons.) For example: under my hand, it is very easy to hold down ButtonRight, the context button while doing another mouse action: scrolling Up/Down (two more Buttons), Scrolling Right/Left (two more Buttons), or pressing a side button. (I've got FOUR of them, even though Qt flushes two of them down the toilet if we ever hand them off to a Qt program.) Or pressing a top button-- I've got 3 more. For me, holding RightButton and spinning the up/down wheel would be a GREAT implementation of scroll in/scroll out. People with more flexibility could use ButtonLeft instead, or in addition to, my use of ButtonRight. For me, ButtonLeft is an easy modifier for only BackButton (AKA XButton1 which is Button #8 from X11), ForwardButton/XButton2 (Button #9), Button #10, and Button #11, Plus wheel up and wheel down (X11 Button #4 and Button #5). So, I'd end up with 5 scroll axis choices, and 12 additional, virtual buttons for invoking various effects and keyboard sequences. Most people with tilt-wheel mice would have 6 'pretty comfortable' scroll axis choices (I have a tendon problem which makes right-left with ButtonLeft a difficult combination for me. Except when typing text, I'd be able to pretty much drive my computer with just the mouse. PART 3, MAYBE: Should we re-organize
re: kdelibs/master: zap it?
In reply to Allen Winter (and Hugo, and Aaron): I feel that Allen's idea/suggestion is really good -- having MYSELF made the mistake of 'poking around' in the master branch for a while. If it had been completely empty of files, I'd have gotten a really big clue instantly. BTW, Will a '4.8' branch eventually be copied from ongoing '4.7', or will we re-create a valid master for 4.8 Dev work?
X11 mouse buttons in qt4, qt5, and KDE: please, PLEASE review this design.
This is inspired by Todd RME's post in Vol 99, Issue 83. Todd's post in
kde-core-devel refers to the original bug number, QTBUG-16092, but that
bug is so riddled with unworkable baggage that I cloned another. The
real work will be in QTBUG-19238. QTBUG-19238 currently contains
start-up work on defining the 3 remaining bits in the //Qt::MouseButton
enumeration byte as actual button numbers.
Blind-siding qt Devs on IRC, with no actual document to look at, led to
the unworkable code of QTBUG-19238. (We fell into a frenzy of incorrect
'Rah, rah, YES WE CAN group-think with each other.) And
bugreports.at.nokia.com is fine for reporting bugs, and submitting code,
but I've never received a response to my requests for design
hints/review before starting to write code. (I got nothing from Devnet,
either.) I'm unable to even get a tentative estimate for the API changes
cutoff date on Qt 4.8.
And so, I'm asking for a design review on these two lists. My idea might
not be quite right, let's get it in order BEFORE I start writing code! I
know that this isn't the right place for such a Design Review, but qt
appears to offers no viable alternative. Please feel free to ignore this
entire post if the particular details of my design aren't of interest to
you.
- - - - -
We have 3 bits available for enumeration of additional buttons without
breaking compatibility. I think that the key to getting all 31 possible
X11 buttons into qt is this: Use only two of them, for the buttons sent
up from X11 as Button10 and Button11. (Those are the raw numbers from
X11, in which the four wheel-scroll buttons DID appear as button
numbers.) Then, instead of using the last bit (x80) to define
Button12, give it a name (e.g., Qt::HigherButton) which indicates that
the Button number (from X11, or another platform interface with good
button support) is GREATER than the one that which I've tentatively
enumerating as Button11. BTW, here's the entire enum which I propose
to use:
enum MouseButton {
NoButton = 0x,
LeftButton = 0x0001,
RightButton = 0x0002,
MidButton= 0x0004, // ### Qt 5: remove me
MiddleButton = MidButton,
XButton1 = 0x0008,
BackButton = XButton1,
XButton2 = 0x0010,
ForwardButton= XButton2,
Button10 = 0x0020,
Button11 = 0x0040,
HigherButton = 0x0080,
MouseButtonMask = 0x00ff
};
Q_DECLARE_FLAGS(MouseButtons, MouseButton)
I tossed in alternate names for 'XButton1' and XButton2', which were
introduced in 4.7): By convention, they are almost universally used as
BACK and FORWARD.
When a User wants to receive MouseButtonPress, MouseButtonRelease, or
MouseButtonDblClick events from higher-numbered buttons, it becomes a
two-step process: First, receive the event, and recognize that the
'HighNumberedButton' value is generic. Then, call a new function which
I'll add into the class:
int QMouseEvent::ButtonNumber () const
which shall return the INTEGER Button number of the most recent
Press/Release/DblClick event. BTW, I feel that this function should also
report the integer values for events which occur with lower-numbered
button values: It would allow programmers to define their Button-based
code blocks by branching on integers. (The alternative is to have one
set of branching control statements built for low-numbered buttons,
using the Enum values; plus another set of branching control statements
built for high-numbered buttons, using Integers. Code like that would
look ugly.)
The whole idea of using an enum which couldn't contain any more buttons
than the miserable XI V1.x Button MASK was a *BAD DESIGN* from the
beginning. Let's support old code without changes, but lets also solve
the problem by making the design correct.
-
I am confused by the plugin design which appears to be present in both
qt4 and qt5. Is the qt5 Wayland plugin really supporting only only
THREE mouse buttons, per the following code from
qt5/qtbase/src/plugins/platforms/wayland/qwaylandinputdevice.cpp?
(a code snippet from gitorious):
void QWaylandInputDevice::inputHandleButton(void *data,
struct wl_input_device *input_device,
uint32_t time, uint32_t button, uint32_t state)
{
Q_UNUSED(input_device);
QWaylandInputDevice *inputDevice = (QWaylandInputDevice *) data;
QWaylandWindow *window = inputDevice-mPointerFocus;
Qt::MouseButton qt_button;
if (window == NULL) {
/* We destroyed the pointer focus surface, but the server
* didn't get the message yet. */
return;
}
switch (button) {
case 272:
qt_button = Qt::LeftButton;
break;
case 273:
qt_button = Qt::RightButton;
break;
case 274:
qt_button = Qt::MiddleButton;
break;
default:
mouse buttons - my view from X11 upwards into Qt
PREAMBLE: Hi. I'm the X11-oriented mouse guy whom Todd mentioned in his last call for GSOC, what about shortcuts? post (Topic #1 in Vol 95, Issue 69). His focus is within KDE itself, while I'm focusing from the lower layers, moving up into KDE Development tools, API, and UI from those lower layers. (X11, the qt-X11 interface, and upwards into signal handling.) I have some ideas about Co-Requisite enhancements to the KDE System Settings Mouse/Pointer Module, and uses within Kwin, Shortcuts, and some other places. This email will NOT address those higher-level KDE modules. There's a lot of fundamental stuff, for which which I will need design advice, and I've been unable to get it so far. I'll be discussing those other areas in follow-up emails, if that's OK. I'm going to need some direction from KDE visionaries, because there are four alternative levels at which we could do this. But first let me show the naming convention which I will be using. ButtonX means the button number which gets emitted from X11. Here's the translation layout which I want to use. Please use it, because we'll get the numbers confused if some replies and new comments INCLUDE wheel events as numbered buttons, while others EXCLUDE the two pairs. And also, lots of existing hardware is built with wrong numbers. Button1 = left button Button2 = right button, AKA context menu button Button3 = middle button Button4 = scroll wheel up Button5 = scroll wheel down Button6 = tilt wheel left, AKA scroll wheel left Button7 = tilt wheel right, AKA scroll wheel right Button8 = back button, AKA XButton1 Button9 = forward button AKA XButton2 Button10 = first additional gamer button Button11 = 2nd additional gamer button Button12 = 3rd additional gamer button ... and so on. Within Qt, the Devs have recognized that Button8 and Button9 are frequently implemented backwards. Thus they assigned the more cryptic names XButton1 and XButton2. But Qt has not considered the possibility of horizontal tilt wheels (or genuine horizontal wheels) implemented on a different pair. And unfortunately, many mice are built with nonstandard numbers. (Even products from a single manufacturer can vary. For example, Logitech emits 6/7 from some models, and 13/14 from different ones- usually older models, but still in widespread use.) Here are the 3 alternatives (within Qt4.x, using XI 1.5) which I've identified for KDE to build upon: (A) Do absolutely nothing in Qt, simply enhance KWin, KDevelop, and etc. to support the buttons which Qt now provides. (B) Add 3 more buttons (Button10 thru Button12), extending the defined enum and mask bits (Qt::MouseButton and QAt::MouseButtons) until they hit a byte boundary. (C) Use 31, bytes. - - - - - ALTERNATIVE (A): DO NOTHING ALL IN QT. I hate this approach, because it's manifestly easy and risk-free for even a child to extend Qt's bit definitions to at least a byte boundary. (With X11; I don't know about other platforms, such as Win32 or OSX, or Symbian. And anyway, OSX support is broken with just 3 buttons, and the authors of the Button8/Button9 updates didn't actually bother with doing the whole job: The automated testing code tools, among other non-production parts of Qt, still don't have them. ALTERNATIVE (B): EXTEND SUPPORT FOR MORE BUTTONS, BUT ONLY TO THE 1ST BYTE BOUNDARY IN THE BUTTON MASK. Add Button10 through Button12. That's a LOT of buttons (although my test mouse, like most gamer mice, has even more). Very safe, with no possibility of compilers doing the wrong thing. ALTERNATIVE (C): DEFINE AND SUPPORT AT LEAST 31 POSSIBLE BUTTONS. This is my recommendation, but it depends on something I don't know: The current enum for Qt::MouseButton defines all values as 32-bit hex values (with leading zeroes): Qt::NoButton 0x The button state does not refer to any button (see QMouseEvent::button http://doc.qt.nokia.com/4.7-snapshot/qmouseevent.html#button()). Qt::LeftButton 0x0001 The left button is pressed, or an event refers to the left button. (The left button may be the right button on left-handed mice.) Qt::RightButton 0x0002 The right button. Qt::MidButton 0x0004 The middle button. Qt::MiddleButtonMidButton The middle button. Qt::XButton10x0008 The first X button. Qt::XButton20x0010 The second X button. I think that an enumerated item with an explicit value will NEVER be compressed, even though a Compiler which wanted to squeeze an enum of 7 items (defined without specific values) into a SINGLE BYTE would be free to do so. If my understanding is correct on all platforms, then we can safely use the entire Uint32. If it isn't, then we'd better stay with ALTERNATIVE-B. BTW, I don't want to define or support Button32 in Qt -- no existing mouse needs it, and it might be useful as some kind of flag bit within a migration of XI -- XI2. Finally,
