Hello, On Wednesday 31 July 2013 17:40:21 Aleix Pol wrote: > As you might know, I've spent some time figuring out what's left to do to > dump KGlobalSettings. I thought it was almost over, but not yet. There's a > bool naturalSorting property that resists. > > It's a full-fledged with a getter, a changed signal and no setter (because > it's only done in one place and the implementor decided to leave it just > there and emit from the kcm code).
Yep, it's clearly dolphin specific, I honestly wouldn't bother much for that one. It'll be up to the dolphin developers to pull in the bits of code they need once they port away from KGlobalSettings, it's a method and a setting behind the method used by only one application. > If we look at how KGlobalSettings work, it's apparent to me that it was a > place where to dump this kind of things. I guess it's quite obvious that > there's a generic use case that we're not fulfilling because of a technical > limitation of KConfig and we have to implement it ourselves. What you have in mind is "notifying across processes of a setting change"? > I've been thinking about how I'd like this to work, and I'd like to propose > a small addition in the kconfig_compiler so that we can tell a property to > advertise itself through dbus (like we were already doing in > KGlobalSettings, but automatically). > > This would add a slightly weird behavior since we're not used to installing > kcfg files and we'd need it in those cases, but I think it can be worth it. Why would we need it? Wouldn't the apps interested in those settings share the generated code (probably encapsulated somehow) instead of the kcfg? > An alternative would be to properly separate the .cpp and the .h files and > install header files but this would mean requiring installing libraries and > different kind of problems such as ABI. > > Any thoughts? Did I miss any obvious feature that defeats the point? I would say the main issue is the timing, we don't really need that *now*. That's something which can be added in 5.1. I'd rather have us focus on what's needed to get 5.0 out of the door now. Regards. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by BlueSystems and KDAB to work on KDE Frameworks
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
