2011/5/27 Emmanuele Bassi <eba...@gmail.com>
> On 2011-05-27 at 18:17, ecyrbe wrote:
> > > > Of course it is. With this bug, programs crash where they other-
> > > > wise could limp on.
> > >
> > > potentially eating away data? without schema you don't have a default
> to
> > > fall back to for application preferences and for state. it might end up
> > > deleting existing account data, for instance. or eating your files.
> > >
> >
> >
> > nope, what you don't seems to understand is that you don't let the
> calling
> > program deal with it.
>
> and how do you propose to deal with that? if you allow the application
> code to run then *anything* can happen, by definition. what's to say
> that an app developer or a plugin developer decides to still go on and
> not write sensible code? or tested code: a missing schema is an
> installation issue, and people barely test error paths.
>
> this might be acceptable for application developers and their own code,
> but this sort of carelessness in designing a platform API is simply
> not acceptable.
>
This is not dconf decision to make, it's the developper one. this where we
are disageeing.
> > With this behavviour
> > you now have to protect your code from crashing by checking everytime
> that
> > the schemas (or even the key) exists.
>
> no, because the schema *has* to exists. why would you want to protect
> from an abort()? don't you use g_assert() to protect internal state? you
> might certainly not do that, but gtk+ does in multiple places.
Because it can happen?
if you are using a plugin hierarchy you will want to protect yourself
from crashing the entire application because of a single plugin.
imagine an anjuta plugin that is badly installed and that uses gsettings.
Then only one plugin can make anjuta crash (imagine a dynamic loading plugin
hierarchy)
So now how can Anjuta protect itself from crashing? there is no way but
adding workaround code on the plugin...
But the right way to do it should be for Anjuta to recover from some
exception mecanism.
But C has no exception mecanism, so you need to make one or let the
developpers deal with the error themselves.
do you want
> to have a callback for gracefully showing an error dialog?
>
this is not going to work for the plugin hierarchy i explained.
> > No data is eaten if the calling application show a gracefull message and
> > exit from itself.
>
> you cannot guarantee that for every application, unless the library
> itself shows that error dialog — an error dialog that will essentially
> be useless for the user ("Schema not installed. Reinstall the
> application"; well, what now?). GIO cannot show error dialogs, so it
> does the next best thing: abort() with an error message meaningful for
> the developer in the error log, which will be caught by the desktop-wide
> system service for application crashes, and will send a bug report.
>
> what we need is a way for the Shell and for applications to be able to
> validate the existence of a schema for their plugins.
>
>
Yes we need a way to validate schema existence for ANY plugin hierarchy
system.
You can't seriously ask that every plugin system in gnome applications to
reinvent this feature. (Gedit, Anjuta,Evolution, Gnome-shell etc)
you have to provide a way to allow them to deal with the error. And the
simplest one is to not abort,
but if you have another suggestion, i'm all ears open.
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
