Revising changing configurations with KConfig

[Aleix Pol]

On Wed, Jul 31, 2013 at 10:51 PM, Kevin Ottens <ervin+bluesystems at kde.org>wrote:

> 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
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>
>
Well, that setting is used in KDirSortFilterProxyModel as well... Should we
just always sort naturally by default there then?

Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130801/6f6dc961/attachment.html>