Global shortcuts for clean qml plasmoids

[Rick Stockton]

On 02/14/2013 12:17 AM, Mark wrote:
> On Thu, Feb 14, 2013 at 8:43 AM, Michail Vourlakos <mvourlakos at gmail.com> wrote:
>> Based on
>> http://kdeblog.mageprojects.com/2012/12/07/application-wide-shortcuts-in-qml-this-time-without-qshortcut/
>>
>> can you provide me with some feedback about how a clean
>> qml plasmoid can create global shortcuts?
>>
>> For example through qml plugins is it a feasible option?
>>
>> Is there a better approach?  (an example code would be more the welcome)
> That's a very interesting message. Specially because i wrote that blog entry :)
> There are a couple of ways that i can think of to get global shortcuts
> working. Everything below is "assumption" based so i could very well
> be wrong!
>
> The first possibility: Qxt!
> http://libqxt.bitbucket.org/doc/tip/qxtglobalshortcut.html If you add
> Qxt to the mix then you will get the ability to use global shortcuts.
> If it's a desirable option.. i don't know.
*****
I don't know whether additional conditions of the CPL license end up
making Qxt unsuitable as a source of "IP" for inclusion/adaptation into
a current or future KDE GUI Class.

But, without looking in sufficient detail to understand how it works --
the Qxt Global and Application Shortcut classes all appear to derive
from QObject, and NOT from QWidget. Very nice, because I have the
impression (as an unqualified bystander) that inheritance from QWidget
(in QShortcut and QAction, and ththe derived "K" classes as well) is not
desirable in a QML-based UI module. It also seems that the LOC which
were necessary to define these Classes in Qxt is remarkably small. I
also haven't attempted to check whether some other required Class (maybe
QxtApplication?) already pulled QtWidget into the mix, in a way I didn't
immediately notice.

Maybe new QShortcut/QAction "glue" can be provided in Qt 5.2, or maybe
the QAction and QShortcut Classes can be re-factored (removing
dependencies on QWidget). Such tasks are non-trivial, far beyond my
abilities.
> A second possibility is one that is quite a bit harder. If i recall
> correctly then you can register a global shortcut in KDE through the
> system settings (shortcut manager i guess?) Then you can "probably"
> use that shortcut using KAction or KShortcut or both. I'm not sure at
> all about this option, but there should be something possible here.
AFAICT, QML elements can respond to QKeySequence() ... but can't get to
the higher-level "KShortcut" and "KAction"  classes without a
significant chunks of code to "ping!" their way into C++ Classes which
inherit (per above) from QWidget.
I hope that some glue can be provided in Qt 5.2, or maybe the QAction
Class can be re-factored to require only Gui Classes, without QWidget.
But that sort of stuff is far beyond my ability.

?
> Both options are not ideal and certainly not clean. If you want a
> clean option then you'd probably need to rewrite the global shortcut
> stuff in KDE (which will need to be done anyway due to wayland,
> something Martin said in another thread).
>
> I hope this helps you. I've been struggling with global shortcuts as
> well and just left it as they are because it's quite complicated.
>

Slightly related speculation from this non-programmer follows. I don't
know how KAction, KShortcut, and KGlobalAccel actually work.

First Question: When "someone" takes on Mouse Shortcuts for KDE, is it
likely that we will need the entire set of "QMouseSequence" + enhanced
"QAction" (with ref to MouseSequence)" + "QShortcut" (ref to
MouseSequence)", with some kind of "MouseShortcutMap" lurking in the
background within Qt....

Or would 100% D-Bus seem like a plausible design, going directly from a
"QMouseSequence" Event (Yes, an Event Type) into one or more "K"
Shortcut Sequence handlers, which rely on D-Bus to route messages to
matching WM and/or program-level D-Bus listener(s)? Since
"QKeySequences", and to-be-defined "QMouseSequences" or
"KMouseSequences" are invoked at only human speed ... maybe the
inter-task communications overhead of D-Bus wouldn't be that noticeable
- even when implemented on ACtions and Shortcuts which are now internal
to a single Application.
.
Perhaps some "Shortcuts" now working via Qt Signal/Slot, limited to a
relatively non-dynamic connection scheme (and internal to a single
application) should  be upgraded to use D-Bus facilities as a part of a
project to add "QMouseSequence" Event support.
At the "KShortcut", "KAction", "KGlobalShortcut" layers, if they don't
use D-Bus already: We could modify the underlying messaging to use the
same D-Bus scheme - advertising changes, invoking listeners,  and
sending returns back to the owning Objects and Elements of the invoking
Events.
(Hmmm - if the overall scheme is viable, maybe Python/GNOME/GTK Apps,
and other Window Managers/ DEs (especially Razor-Qt) might also be able
to share such a D-Bus implementation of shortcut advertising, Reverse
DNS Prioritization, and invocation/return messaging WITH KDE :))



Am I making any sense at all? This is a SWAG, so please feel free to
reply "No, it doesn't make any sense!, and/or "Yeah, but we already do
that!"

Keep in mind, QMouseSequence() is probably going to be a lot more simple
than QKeySequence(), because there are no "Standard Key" mouse
combinations which vary according to runtime platform. I imagine it to
be a single Mouse Event signature, optionally followed by ONE keyboard
event.