From kde-panel-devel Wed Feb 20 08:59:52 2013 From: Mark Date: Wed, 20 Feb 2013 08:59:52 +0000 To: kde-panel-devel Subject: Re: Global shortcuts for clean qml plasmoids Message-Id: X-MARC-Message: https://marc.info/?l=kde-panel-devel&m=136135084114783 On Wed, Feb 20, 2013 at 7:01 AM, Rick Stockton wrote: > On 02/14/2013 12:17 AM, Mark wrote: >> On Thu, Feb 14, 2013 at 8:43 AM, Michail Vourlakos 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. _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel