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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
