API for binding and unbinding a key combo?

[Aaron J. Seigo]

On Monday 31 March 2008, Bastien Nocera wrote:
> > 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.

some of the methods/signals could be named a lot better indeed and there has 
been some recent changes to e.g. the number of arguments in the string list 
passed in to rpepresent an action.

as for other platform support: MacOS has an implementation as well, but not 
Windows yet, it's just stubs at this point. the win32 team will eventually 
get to it.

> > That's why I was offering to look into making this an fd.o standard.

with a bit of scrubbing it could indeed work out nicely.

> 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).

because not all apps that register keybindings have a UI, because it's a 
runtime issue that needs to be resolved before getting to the config UI ...

> Why would applications (via kdelibs) be using those in the first place?

using which? global accels? because they can. think of media apps, desktop 
shell bits, things like "print screen". we don't control 3rd party developers 
and users can also set up their own globals.

> 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.

which may be acceptable for users of GNOME apps at configuration time. i don't 
see how it solves the runtime issues or 3rd party issues.

conflicts are only meaningful when the application(s) is actually running, and 
it is at the moment that they are running that one needs to manage this. just 
because two apps have the same shortcuts doesn't mean anything unless they 
are run simultaneously. (think of apps that are replacements for each other: 
they may implement the same keyboard interfaces ..)

> 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.

but that's not what the d-bus interface is for. kde4 too has a configuration 
UI for dealing with management of the accels, but the d-bus interface is for 
runtime registration and resolution.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/xdg/attachments/20080331/fe634b00/attachment.pgp