[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: Global shortcuts for clean qml plasmoids
From:       Mark <markg85 () gmail ! com>
Date:       2013-02-20 8:59:52
Message-ID: CAPd6JnHm4GSP9m_0ijc6xw33Z3eA7sdDJdzb=2FaxXWRufVHMw () mail ! gmail ! com
[Download RAW message or body]

On Wed, Feb 20, 2013 at 7:01 AM, Rick Stockton
<rickstockton@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@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.
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


[prev in list] [next in list] [prev in thread] [next in thread]