Review Request: port Sonnet to QSettings

[Martin Tobias Holmedahl Sandsmark]

On Thu, Dec 27, 2012 at 12:18:21PM -0000, Kevin Krammer wrote:
> Two levels are most likley the most common case because most systems do not
> have any system administrator. Once you have admin customization you have
> at least three (package, admin, user). I don't have any evidence for nor
> against usage of Kiosk features in regard to spell checking, I am just
> pointing out that the solution proposed here does have none of those.

Well, the library in question here does spell checking, so that's what we
should focus on. IMHO spell checking doesn't need any of the extra features
offered by KConfig.

> The reuse of the filename "sonnetrc" suggest to me that the intention is to
> use the same file. A KConfig based application and a QSettings based
> application will behave inconsitently if using the same file. Or is this a
> per-application stored file?

Do I use sonnetrc anywhere? In that case I missed something.


> Do we assume that KDE application developers who's programs are being used
> in an "Enterprise" setup will fork the library and reimplement the config
> with KConfig or do we want them to use the KF5 version? The later will
> either require that the library does not handle config itself or at least
> allows applications to intercept config access or provide config that takes
> precendence over stored config.

If they care about that they can just load using whatever config system they
want, and set the loaded options manually.

I also don't think this is a very likely scenario, tbh.


> IMHO the most sensible case is to let the application handle config I/O,
> allowing it to store the config in a way that is most approriate for its
> usage. If that is a KConfig INI file, a simple QSetting INI file or a JSON
> file shouldn't really matter to an engine which only is interested in the
> values.

I think the most sensible is to not let the application developers bother
their pretty little heads with storing the config at all if they don't want
to.

With what I have proposed here they can reimplement the config storage if
they want to, but by default It Just Works™.


-- 
Martin Sandsmark