Mouse Shortcuts (was: Qt 5.1 feature set and freeze date)

[Rick Stockton]

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.

-- 
GPG fingerprint: 597E 4CE5 6D56 A7C2 DA3A 26FF F21F F828 0C86 165A