viability of implementing global shortcuts via KDED and DBus

[Andreas Hartmetz]

On Friday 11 May 2007 11:45:40 Lubos Lunak wrote:
> On Friday 11 of May 2007, Andreas Hartmetz wrote:
> > 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.
>
>  I think what Thomas meant was that the conflict resolution should be
> handled by IPC, instead of parsing a config file all the time; it wasn't
> about where XGrabKey() should be done (where kded module would be a best
> place it seems).
>
That is exactly what I want to do - I didn't make it clear enough apparently.
Each KGlobalAccel should only know its own actions and shortcuts as far as 
needed and call KDED for anything else, *especially* conflict resolution.
Config file parsing would only happen once when the KDED module loads.

Nice piece of work that I have assigned to myself, not knowing DBus or X. At 
least I have some X documentation now due to Lubos.

> > Erm by the way, can one rely on the presence of KDED, even when running a
> > KDE application in another DE's session?
>
>  Kdeinit (which also launches kded) can be started on-demand if needed. See
> e.g. KToolInvocation::klauncher().
>
Nice, very nice.

> > (*) 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.
>
>  Arguably. If I have both KSCD and Amarok and they both have 'Next track'
> global shortcut, should I really be prevented from using the same shortcut?
> Not that I really know the right answer.