[Development] Mouse Shortcuts

[Rick Stockton]

On 02/13/2013 12:01 PM, Mark wrote:
> On Wed, Feb 13, 2013 at 8:05 PM, Rick Stockton
> <rickstockton at 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.Knoll at 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 + 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.