Re: About gsettings aborting on unkown schemas

[Emmanuele Bassi <ebassi gmail com>]

On 2011-05-27 at 08:51, Hubert Figuiere wrote:
> On 11-05-27 5:43 AM, Emmanuele Bassi wrote:
> > On 2011-05-27 at 13:42, ecyrbe wrote:
> >> I just filled this bug : https://bugzilla.gnome.org/show_bug.cgi?id=651225
> >> Mathias closed it as wontfix, this is by "design".. i'm told that it's not a
> >> bug it's a feature!
> > 
> > it's not a bug.
> 
> It is a bug.

where were you people in 2004 when Havoc outlined all the issues of
GConf and this was the one thing to fix? :-p

> > the rationale is: schemas are an integral part of an application or a
> > library exposing settings. it's like the .ui file for applications
> > creating their user interface through GtkBuilder. there is no amount of
> > magic in the world that can save you from a missing .ui file. without
> > the schema, the settings system cannot identify default values, key
> > names or *anything* else about the settings.
> 
> First, if the UI file is missing the application does not abort.

yes, a UI is actually (barely) recoverable. you just die with an error
message, to which the user will have absolutely no idea how to respond
to.

> Second the actual requirement of the schemas is part of the problem,
> even though that's not the original complain. Even more so that it does
> not seems to be possible to load a schema at runtime or to have it in a
> specific prefix... unlike in gconf. GSettings is a huge regression in
> gconf: read my words. It is WORSE.

read my words: it's definitely not. because when I use GConf I have to
add three times the amount of code to handle the default values in case
the schema is missing or broken or the daemon simply decides to go
insane. with GSettings if I depend on a schema, I don't have to second
guess every call to settings.get(): I'll either get the default or get
the stored value, and it will have the correct type.

> Third, passing a NULL widget to gtk_widget_(), or the wrong type does
> not cause an abort. And this is likely a programmer error with barely no
> external side effect, unlike the gsettings schemas.

invalidating the internal state in every library from glib up to
whatever will hit g_assert() as some point or other.

> > 
> >> So if my desktop is crashing it's a feature and nobody is willing to fix
> >> it?I really would like to have another answer than this one.
> > 
> > if your desktop is crashing then it means that some part of it is
> > relying on a file that is not there. try randomly removing a shared
> > library from your system, and you'll obtain the same behaviour.
> 
> Wow. So basically you are saying that instead of having a SOLID
> foundation we should have a fragile system with so many component?

oh, please. let's complain that g_malloc() will abort(), then. I haven't
heard about that for a while.

> Weren't you complaining about the lack of MacOS-style bundles you seem
> to be pretty inconsistent: one of the thing that MacOS-style bundles
> permit is it actually install an application by copying ONE SINGLE item.
> But with gsettings this is just impossible. The dicatorship of
> distributions like you call it is right here[1].
> 
> [ screenshot of the tweet by use @ebassi ]

setting different search paths, which is how bundles work, should work
for GSettings; it is a currently pending issue, one that Ryan intends to
solve with the minimal impact on the API entry points.

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi