Revising changing configurations with KConfig

[Kevin Ottens]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130731/83aa5424/attachment.sig>