<div dir="ltr">On Wed, Jul 31, 2013 at 10:51 PM, Kevin Ottens <span dir="ltr"><<a href="mailto:ervin+bluesystems@kde.org" target="_blank">ervin+bluesystems@kde.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

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

</div><div>Aleix</div></div></div>