On 02/14/2013 12:17 AM, Mark wrote: > On Thu, Feb 14, 2013 at 8:43 AM, Michail Vourlakos <mvourla...@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. _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel