On Mon, 2008-03-31 at 11:52 +0100, Thiago Macieira wrote: > On Monday 31 March 2008 12:23:22 Bastien Nocera wrote: > > Well, that's pretty much what we want to do as well, to avoid > > applications having their own code, and needing to be running to capture > > the key (we've already got the first and last bullet items, and want to > > implement the second one). > > > > What about the D-Bus API? > > Currently what we have is this: > > http://websvn.kde.org/trunk/KDE/kdelibs/kdeui/shortcuts/org.kde.KdedGlobalAccel.xml?revision=688478&view=markup > > It accesses the object /modules/kdedglobalaccel on org.kde.kded. > > As the comments indicate, this interface is not meant for public consumption. > It's just used for communication internally between KDE libraries and the > daemon. > > That's why I was offering to look into making this an fd.o standard.
That seems like a way to put the conflict resolution UI and the shortcut settings in kded instead of having it solely in the front-end application (the keybindings UI). Why would applications (via kdelibs) be using those in the first place? In GNOME, we have the definitions in XML files (so applications can drop their own definitions), and the configuration is stored in GConf (so gnome-settings-daemon get notifications when changed). The UI is the only one to know about conflicts, and conflict resolution. I don't think that having a D-Bus interface for the sole purpose of being able to replace the front-end would be that interesting. _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
