On Monday April 11 2016 09:44:26 Martin Sandsmark wrote: Morning,
It seems I was a bit confused. I posted this question because I had to introduce a new patch to force the use of IniFormat, but that was not in Sonnet itself but for some new setting in KTextWidgets :-/ Same question/principle applies there, of course, as in KTextEditor. IOW, I might be looking at 3 review requests (?) >Well, we shouldn't? Sonnet is at least used by Quassel on Windows AFAIK, and >probably (hopefully) others. But if you don't think it is something that we >need to care about I won't argue. I'd say it depends a bit on how disruptive loss of these global settings is going to be (i.e. how many dependents override the global settings) but usually I'm all for migrating old settings. So I have no objection against importing from NativeFormat in Settings::restore() but someone would need to give me a hint how this is done. Open 2 settings instances (pointers in that case, I presume) and read from the NativeFormat instance if the IniFormat one is empty (allKeys().isEmpty())? In fact, there might even be an argument for continuing to support both formats during a certain time, on platforms where applications will tend to ship their own copies of the frameworks. Given the frequency with which the frameworks are updated it's more than likely that users will end up with application bundles/install that do not all use the latest frameworks version. Users who notice the loss of their (Sonnet) settings because of the format change might also wonder why not all applications respect settings changes they make in a given application. OTOH, if that is really a consideration one should probably consider a convenience class that handles this scenario: - read from the NativeFormat settings if there are no IniFormat settings (or if the NativeFormat settings are newer, supposing that is an observable). - write to IniFormat settings, and also to NativeFormat if such settings exist. (of course such a class would be auto-deprecating, and mostly to the benefit of "outdated" installs.) René _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
