1. actually it's not a problem of this library, though using default values - is a big advantage.
BTW even fixing a "plain text" ini files can be troublesome. Try to fix something like: State="@ByteArray(\0\0\0\xff\0\0\0\x2\xfd ... 4 more lines ... \xfc\0\0\0\0)" ;-) (it's from QtCreator.ini)

2. I'll see what I can do to expose this functionality in API.

3. well, I looked close at dconf-qt and I'm sure we want to use our own solution.
I think we'll create a similar (but not an exact copy) API to QSettings to some extent - as was mentioned before dconf-based settings have some additional features like descriptions and default values, but do not have scopes, fallbacks and formats as QSettings class does.
And if one day Qt supports dconf natively - we'll see, maybe there will be no advantage to migrate.

4. Actually, I was going to preserve types as much as possible, but just as a concept your class is great!

Cheers,
Kuzma


On 7 August 2013 18:10, Jerome Leclanche <adys.wh@gmail.com> wrote:

On Wed, Aug 7, 2013 at 7:00 AM, PCMan <pcman.tw@gmail.com> wrote:
On Wed, Aug 7, 2013 at 1:29 PM, Kuzma Shapran <leaf.on.wind@gmail.com> wrote:
> @PCMan: I looked at lxqt-settings - it's good start. I'm currently improving
> it in my fork (https://github.com/kuzmas/lxqt-settings) - some style
> formatting, C++ vs. C ways of doing things, and the main: hiding
> implementation into a private class to have more or less stable ABI.
>
> @Christian: Also I looked at dconf docs - there is a way to monitor
> modifications, so adding signals for this is in my todo list as well.
>
> Cheers,
> Kuzma

Thank you for taking this over.
I'm sure you'll make it better.
While doing dconf thing, I encountered some problems, though.

1. The config is stored using a binary format. What will happen if
it's corrupted? There is no easy way to fix a broken configuration
without using either a GUI editor "dconf-editor" or a command-line
tool. Fixing a wrong plain text config file with an editor is much
easier. When something goes wrong and you cannot login your desktop
session, it's hard to fix the config with command line tools. If we
can have a set of "default values" and can let the user restore the
default easily, this solves the problem partially.

2. While the glib implementation GSettings supports schemes, default
values, and type checking, my implementation just does raw read and
write for the values. No type checking or default values are handled.
It might be better to use glib GSettings? Otherwise, default values
need to be hard-coded in applications themselves.

This was, once again, brought up at the desktop summit (to much heat). Qt would never itself have a gsettings backend (not in its current state) as it doesn't want the dependency on GIO. I don't think we want that either.
Ryan Lortie brought up that gsettings could possibly become more independent, which would be interesting, however I haven't followed up on that.
 

3. Should we use dconf-qt, which is done by Canonical instead, or
using our own simple class mimicking QSettings? Personally I prefer
our own solution and this can be included in liblxqt.

Seeing as dconf support will ultimately end up in Qt (god knows when, though), I recommend we use our own solution for the time being and eventually switch to the native one.
 

4. Currently, I store everything as strings, mimicking what QSettings
does. Dconf, however, is aware of different data types. So integers
and some other types can actually be stored in their binary forms
directly rather than all converted to strings. As a proof of concept,
I did not do it and just convert everything to strings for ease of
implementation. Please feel free to fix this part.

Thanks

--
--
You received this message because you are subscribed to the Google
Groups "Razor-qt" group.
For more options, visit this group at
http://groups.google.com/group/razor-qt?hl=en

---
You received this message because you are subscribed to the Google Groups "Razor-qt" group.
To unsubscribe from this group and stop receiving emails from it, send an email to razor-qt+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.