On Mon, Jan 26, 2015 at 10:01 PM, Albert Astals Cid <aa...@kde.org> wrote: > Yeah, i don't think that what you suggest really helps much, otherwise you'd > end up with two kglobalaccels running at the same time, which is probably a > very bad thing.
It's dbus invoked, so in the kglobaccel case specifically david edmundson suggested that correct naming of the service file in frameworks would make sure that it is the file used by dbus-daemon to run the service. A potentially more interesting problem would be KIO slaves moving about, as I don't think there is any provisioning for two slaves providing the same protocol and having one outrank the other. > So yes, a better way of moving thing arounds is needed, or maybe we just need > the dust to settle a bit so that we realize where each thing really belongs > and it'll hopefully fix itself? Waiting for the dust to settle is what I have been told for almost a year now. How much more dust can there possibly be? :P The problem IMO is that supposedly the existing things will settle at some point, that doesn't mean a new thing couldn't end up in some plasma repo for 5.7 and then be moved into a framework 5.130 because it suddenly fits better into frameworks. As a community we should at the very least decide whether or not frameworks ought to be runtime compatible with non-frameworks bits (such as plasma) and follow through with that. If we don't want to have this level of compatibility then it's fine as well, it just needs to be made clear I feel. As of right now I don't think anyone ever told me that runtime bits aren't supposed to be compatible when I highlighted a conflict because of things moving about. It always was a lot of handwaving and explaining that things are still changing. And to be quite honest, if things are changing such that I can not upgrade my frameworks without having to recompile or upgrade something unrelated as well, that feels a lot like a BIC. HS _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
