Le vendredi 27 mai 2011 à 19:04 -0700, Hubert Figuiere a écrit : > My code is *designed* to actually manage default value. Like UI > has default that people whine about. This is just good programing practice. While I can perfectly conceive we might need a way to avoid crashing when a schema is missing (e.g. when loading broken plugins), I really think code designed to manage default values is wrong. And that's exactly what GSettings's behavior is meant to prevent. What the point of duplicating information in the schemas and in the code?
In the good GConf times, you had to create several code paths every time you read a key in case the setting wasn't valid, or had no default. And then you had to keep the hardcoded default in sync with the schemas to avoid a big mess. With GSettings, that's easy: you're guaranteed to get a correct value, and in the worst case the default. You don't need any if() in your code, and you can change the default just by editing the schema. GSettings was designed with the idea that settings can't be missing in mind. As Havoc said, consider them as being part of the code (at least as a metaphor). There's no good reason a program should have missing schemas - except maybe in the case of plugins. Cheers _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list