On 02/13/2013 12:01 PM, Mark wrote: > On Wed, Feb 13, 2013 at 8:05 PM, Rick Stockton > <[email protected]> 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 <[email protected]> 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 + Mouse<key> 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. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
