viability of implementing global shortcuts via KDED and DBus
ahartmetz at gmail.com
Fri May 11 01:46:43 BST 2007
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
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
By the way #2, KGlobalAccel's current DBus interface is a stub and the Apidox
are out of sync (will fix Apidox tomorrow).
More information about the kde-core-devel