API for binding and unbinding a key combo?
Aaron J. Seigo
aseigo at kde.org
Mon Mar 31 07:06:15 PDT 2008
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
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/xdg/attachments/20080331/fe634b00/attachment.pgp
More information about the xdg