On Wed, Aug 7, 2013 at 7:00 AM, PCMan <[email protected]> wrote:

> On Wed, Aug 7, 2013 at 1:29 PM, Kuzma Shapran <[email protected]>
> 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 [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
Lxde-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lxde-list

Reply via email to