On 26 December 2013 17:50, Emil Dudev <emildu...@gmail.com> wrote: > Actually, when I started working on this, I changed the code in the > following way: > Read data from the GSettings database, write to both GSettings and GConf. > But I changed my mind, when I saw the article. Guess I'll make an > other commit, with my original idea. >
To be clear, I don't think we should do that for all the settings, only for the few used by activities. > As noted above, the only activities I have, which use GConf are read, > write and browse. > For read and write I have made the necessary changes to drop GConf and > I'll make the merge request in a minute. > For browse, I have made only a small change. But there is an other problem. > > The problem with browse (and possibly, other activities) is that > GSettings does not allow new keys to be created at runtime. Moreover, > if sugar attempts to read a key, which doesn't exists, it will close. > An exception won't be thrown, it won't hang up, it will just close > with a single line in the log. > This is a serious downfall for activities, which use custom keys. > These keys have to be included in sugar's schema file, or sugar should > allow activities to define their own schemas. > Duuh, good catch. We might also have issues in Sugar, I'm not too sure all the keys are in the schemas, we should verify that. About activities, there is probably a way to make them ship schemas but I'm wondering what's the advantage for them to use gsettings vs a json or ini file. It feels like added complexity without real advantages.
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel