Global shortcuts for clean qml plasmoids

[Mark]

On Wed, Feb 20, 2013 at 7:01 AM, Rick Stockton
<rickstockton at reno-computerhelp.com> wrote:
> 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.

You have a habit of writing long mails, don't you ;)
I don't have any answers for you, sadly. I'd like to know as well.