viability of implementing global shortcuts via KDED and DBus

[Andreas Hartmetz]

Hi all,

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.


-What about security? Only real KGlobalAccel objects should be able to talk to 
the KDED module in all circumstances. There seem to be provisions for this in 
DBus, but how do they work, especially in QtDBus?

-How long are typical DBus method invocation times? Shortcuts should trigger 
their actions with no noticeable delay. Assigning saved shortcuts to their 
actions at application startup time should be very fast, too.

-If an application shuts down unexpectedly, can one be 100% sure that KDED 
will get to know it immediately?

-Synchronous calls will probably be needed in places where atomic updates will 
be required to prevent race conditions (not sure if that happens). Can 
synchronous calls be made lockup-proof? A locked up application should never 
be able to block the KDED module. On the other hand, locked up applications 
should still receive updates to their actions ASAP :/

-Chances are that I missed something critical :)

So, what do you think?

By the way, public API changes will probably not be needed. KGlobalAccel is 
designed as an interface class to encapsulate action activation and shortcuts 
bookkeeping.
By the way #2, KGlobalAccel's current DBus interface is a stub and the Apidox 
are out of sync (will fix Apidox tomorrow).

Cheers,
Andreas