viability of implementing global shortcuts via KDED and DBus

[Andreas Hartmetz]

On Friday 11 May 2007 07:44:08 Thomas Zander wrote:
> On Friday 11 May 2007 02:46:43 Andreas Hartmetz wrote:
> > I have recently reimplemented KGlobalAccel to implement proper global
> > shortcut conflict resolution. To that end, every application has to
> > have a list of all global shortcuts that has to be loaded from a global
> > config file. This is neither space nor CPU efficient, especially at
> > application startup time (bad!).
> >
> > It would be nice to have a KDED module that listens to keypresses like
> > the current KGlobalAccel does and that also does the bookkeeping.
> > As I have no DBus experience, there are some issues on which I am
> > asking anyone with DBus/QtDBus knowledge for comments.
>
> I suggest turning it around; let the application query some global object
> via dbus and get a list of conflicting keypresses only (low memory).
> You should do this (shortly) after the app shown its window to avoid
> network latency slowing down the startup, but my guess would be that it
> would be faster than loading / parsing files from disk.

OK, nice idea but not fully thought through, or I didn't get what you mean.
Here is why this would not work very well:

Conflicts are not static (new applications register their shortcuts (*) , the 
user changes shortcuts), so the general case is not simple.
Information about all present and "sleeping" global global shortcuts needs to 
be present or retrievable at any time.
I think that the best place to handle this would be a KDED module that reads a 
list from a global config file at startup and then keeps itself up to date 
via DBus. KGlobalAccel would not need to be much more than an interface.

There is one other problem that I didn't mention - multi-key shortcuts with 
the same first key, but in different applications.
You can only grab a one-key "sequence" in X, which works like that: as soon as 
the key with correct modifiers is pressed in any application, the application 
that grabbed the key gets a full keyboard grab until it decides to release 
the keyboard.
Which application should now get the keyboard grab?
Some trickery would be needed to make this work, and I hate tricks :)
Portability would also be questionable.

These are the two reasons is why using KDED to handle key listening *and* 
action invocation would be the simplest approach.

Erm by the way, can one rely on the presence of KDED, even when running a KDE 
application in another DE's session?

(*) Global shortcuts of applications that are not running should be remembered 
to protect them from conflicts, especially user made conflicts by shortcut 
editing. The old system cannot do this, which arguably needs to be fixed. Not 
that people were flooding bugzilla about this, but designing something 
obviously incomplete is not nice.