From: PCMan <pcm...@gm...> - 2013-07-29 17:25:32
|
Hello, To see how dconf works and make our evalation easier, I created a simple class providing the same interface as QSettings, but uses dconf internally. It's a reusable C++ class - LxQt::Settings, a drop in replacement for QSettings based on dconf. https://github.com/PCMan/lxqt-settings It's a proof of concept. I only implement a subset of QSettings methods. Besides, I haven't implement change notifications, either. (QSettings IIRC does not support this) Data stored are all strings, just like what QSettings stores in ini files. However, dconf actually supports more data formats than string. So, there are still rooms to improve this rough implementation. I did not use glib GSettings since we do not need the features it provides. So I call low level dconf client API instead. main.cpp domonstrated how to use the class. It's just like QSettings. Comments are wanted. Thanks! |
From: <chr...@su...> - 2013-07-29 22:53:03
|
mandag den 29. juli 2013 skrev PCMan : > Hello, > To see how dconf works and make our evalation easier, I created a > simple class providing the same interface as QSettings, but uses dconf > internally. > > It's a reusable C++ class - LxQt::Settings, a drop in replacement for > QSettings based on dconf. > > https://github.com/PCMan/lxqt-settings > > It's a proof of concept. I only implement a subset of QSettings methods. > Besides, I haven't implement change notifications, either. (QSettings > IIRC does not support this) > Data stored are all strings, just like what QSettings stores in ini files. > However, dconf actually supports more data formats than string. > So, there are still rooms to improve this rough implementation. > > I did not use glib GSettings since we do not need the features it > provides. So I call low level dconf client API instead. > > main.cpp domonstrated how to use the class. > It's just like QSettings. > > Comments are wanted. > Looks good to me. I was pondering a different approach: Looking at the source code for QSettings one can see that QSettings keeps an instance of the abstract class QPrivateSettings that handles communication with the backend. By choosing a concrete subclass such as QConfFileSettings or QWinSettings QSettings can chose the backend (ini-files or windows-registry). So I thought that if we could make a subclass of QPrivateSettings for dconf and inject it into a QSettings instance, we'd be good to go. However this has the problem of relying on QPrivateSettings, which is marked as not intended for external use. So your approach is best I think. lxqt-settings will probably need to emit a signal when settings change. RazorSettings, which work on top of QSettings, sets up filewatchers to be able to emit signals on change, and this won't work anymore. br. Chr. > 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 raz...@go.... > For more options, visit https://groups.google.com/groups/opt_out. > > > |
From: Kuzma S. <lea...@gm...> - 2013-08-07 05:30:05
|
@PCMan: I looked at lxqt-settings <https://github.com/PCMan/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 On 30 July 2013 10:52, chr...@su... <chr...@su...> wrote: > > > mandag den 29. juli 2013 skrev PCMan : > > Hello, >> To see how dconf works and make our evalation easier, I created a >> simple class providing the same interface as QSettings, but uses dconf >> internally. >> >> It's a reusable C++ class - LxQt::Settings, a drop in replacement for >> QSettings based on dconf. >> >> https://github.com/PCMan/lxqt-settings >> >> It's a proof of concept. I only implement a subset of QSettings methods. >> Besides, I haven't implement change notifications, either. (QSettings >> IIRC does not support this) >> Data stored are all strings, just like what QSettings stores in ini files. >> However, dconf actually supports more data formats than string. >> So, there are still rooms to improve this rough implementation. >> >> I did not use glib GSettings since we do not need the features it >> provides. So I call low level dconf client API instead. >> >> main.cpp domonstrated how to use the class. >> It's just like QSettings. >> >> Comments are wanted. >> > > Looks good to me. > > I was pondering a different approach: Looking at the source code for > QSettings one can see that QSettings keeps an instance of the abstract > class QPrivateSettings that handles communication with the backend. By > choosing a concrete subclass such as QConfFileSettings or QWinSettings > QSettings can chose the backend (ini-files or windows-registry). > So I thought that if we could make a subclass of QPrivateSettings for > dconf and inject it into a QSettings instance, we'd be good to go. > However this has the problem of relying on QPrivateSettings, which is > marked as not intended for external use. So your approach is best I think. > > lxqt-settings will probably need to emit a signal when settings change. > RazorSettings, which work on top of QSettings, sets up filewatchers to be > able to emit signals on change, and this won't work anymore. > > br. Chr. > > > >> 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 raz...@go.... >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > ------------------------------------------------------------------------------ > Get your SQL database under version control now! > Version control is standard for application code, but databases havent > caught up. So what steps can you take to put your SQL databases under > version control? Why should you start doing it? Read more to find out. > http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > > |
From: PCMan <pcm...@gm...> - 2013-08-07 06:00:21
|
On Wed, Aug 7, 2013 at 1:29 PM, Kuzma Shapran <lea...@gm...> 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. 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. 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 |
From: Jerome L. <ad...@gm...> - 2013-08-07 06:10:29
|
On Wed, Aug 7, 2013 at 7:00 AM, PCMan <pcm...@gm...> wrote: > On Wed, Aug 7, 2013 at 1:29 PM, Kuzma Shapran <lea...@gm...> > 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 raz...@go.... > For more options, visit https://groups.google.com/groups/opt_out. > > > |
From: Kuzma S. <lea...@gm...> - 2013-08-07 06:51:21
|
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 <ad...@gm...> wrote: > > On Wed, Aug 7, 2013 at 7:00 AM, PCMan <pcm...@gm...> wrote: > >> On Wed, Aug 7, 2013 at 1:29 PM, Kuzma Shapran <lea...@gm...> >> 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 raz...@go.... >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > |
From: Kevin K. <and...@gm...> - 2013-08-07 08:31:08
Attachments:
signature.asc
|
On Wednesday, 2013-08-07, Kuzma Shapran wrote: > 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) Well, since this is a binary value it nicely proves the point, doesn't it? :) Here the overall text nature of the config at least allows one to remove the setting (thus falling back to defaults). Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring |
From: Kevin K. <and...@gm...> - 2013-08-07 08:29:07
Attachments:
signature.asc
|
On Wednesday, 2013-08-07, Jerome Leclanche wrote: > On Wed, Aug 7, 2013 at 7:00 AM, PCMan <pcm...@gm...> wrote: > > 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. Not to forget that there is a third option: contribute an implementation to Qt upstream and then use oficial Qt API. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring |
From: Jerome L. <ad...@gm...> - 2013-08-07 09:40:41
|
That would be ideal =) J. Leclanche On Wed, Aug 7, 2013 at 9:28 AM, Kevin Krammer <and...@gm...> wrote: > On Wednesday, 2013-08-07, Jerome Leclanche wrote: > > On Wed, Aug 7, 2013 at 7:00 AM, PCMan <pcm...@gm...> wrote: > > > > 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. > > Not to forget that there is a third option: contribute an implementation > to Qt > upstream and then use oficial Qt API. > > Cheers, > Kevin > > -- > Kevin Krammer, KDE developer, xdg-utils developer > KDE user support, developer mentoring > |
From: Pier L. <pie...@gm...> - 2013-08-07 09:29:47
|
2013/8/7 Kevin Krammer <and...@gm...>: > On Wednesday, 2013-08-07, Jerome Leclanche wrote: >> On Wed, Aug 7, 2013 at 7:00 AM, PCMan <pcm...@gm...> wrote: > >> > 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. > > Not to forget that there is a third option: contribute an implementation to Qt > upstream and then use oficial Qt API. I recently shared my work on the Qt development mailing list: http://lists.qt-project.org/pipermail/development/2013-July/012028.html Currently there's a class that reads a JSON schema, sort of what GSettings does, and offer a simple value()/setValue() API much like current QSettings. This is currently done at runtime but I realize now that it's pretty complicated to get it right, I see benefits moving the burden to compile time much like KConfig does. A cli program would read the schema and generate a nice C++ class, maybe even QML code if asked to, with proper typing and default values. The plan is: - Simple QObject class that loads and saves properties defined in derivate classes for C++ applications (something like Qt.labs.settings, see http://lists.qt-project.org/pipermail/development/2013-July/011719.html) - Lay down an API for backends - dconf backend (I have a desperate need for changes notifications sooner rather than later) - INI backend to be used by default - cli program to generate code from a schema Help on this would be awesome. My goal is to get it included in Qt, this means that you can use it now and transition to the Qt API should be smooth. The source tree supports both Qt 4 and Qt 5. -- Out of the box experience http://www.maui-project.org/ |
From: Samuel S. <s.s...@go...> - 2013-08-07 10:01:24
|
2013/8/7 Pier Luigi <pie...@gm...>: > 2013/8/7 Kevin Krammer <and...@gm...>: >> On Wednesday, 2013-08-07, Jerome Leclanche wrote: >>> On Wed, Aug 7, 2013 at 7:00 AM, PCMan <pcm...@gm...> wrote: >> >>> > 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. >> >> Not to forget that there is a third option: contribute an implementation to Qt >> upstream and then use oficial Qt API. > > I recently shared my work on the Qt development mailing list: Hi, sounds great. > > http://lists.qt-project.org/pipermail/development/2013-July/012028.html > > Currently there's a class that reads a JSON schema, sort of what > GSettings does, and offer a simple value()/setValue() API much like > current QSettings. > This is currently done at runtime but I realize now that it's pretty > complicated to get it right, I see benefits moving the burden to > compile time much like KConfig does. > A cli program would read the schema and generate a nice C++ class, > maybe even QML code if asked to, with proper typing and default > values. ^^^ This sounds much like what google is doing with their protocol buffer library [1]. The protoc (protocoll compiler) generates c++ code from a schema that then offers functions to get/set/default/validate/serialize the data etc. While the purpose is different the technique sounds related. [1] http://code.google.com/p/protobuf/ -- Regards Samuel |
From: Kevin K. <and...@gm...> - 2013-08-07 11:49:07
Attachments:
signature.asc
|
On Wednesday, 2013-08-07, Pier Luigi wrote: > 2013/8/7 Kevin Krammer <and...@gm...>: > > Not to forget that there is a third option: contribute an implementation > > to Qt upstream and then use oficial Qt API. > > I recently shared my work on the Qt development mailing list: > > http://lists.qt-project.org/pipermail/development/2013-July/012028.html Nice work! > Currently there's a class that reads a JSON schema, sort of what > GSettings does, and offer a simple value()/setValue() API much like > current QSettings. > This is currently done at runtime but I realize now that it's pretty > complicated to get it right, I see benefits moving the burden to > compile time much like KConfig does. > A cli program would read the schema and generate a nice C++ class, > maybe even QML code if asked to, with proper typing and default > values. Might be as simple as adding Q_PROPERTY macros for each setting to the generated classes if the config keys are not hierachical. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring |