Re: GtkBuilder report

[Tristan Van Berkom <tvb gnome org>]

On Tue, 2007-01-23 at 20:22 +0000, Emmanuele Bassi wrote:
> hi Brian;
> 
> On Tue, 2007-01-23 at 11:03 -0800, Brian J. Tarricone wrote:
>  
> > > Not really a blocker IMO.
> > > It's easier to add error handling code when you find broken glade files or
> > > are adopting an existing program to output something GtkBuilder can parse.
> > > libglade does well here, so we should definitely improve this at some point.
> > 
> > IMO, this is *definitely* a blocker.  assert()/abort() statements have
> > no place in a shared library[1].
> 
> you arrive a little late: GLib and GTK+ already use assertion failures
> to check for the internal state of the library.
> 
> >   As an application developer --
> > especially a _GUI_ application developer -- I expect that the libraries
> > I use will not terminate my application, ever.  If something Very
> > Bad[tm] happens inside the library (even if it's my fault), I want to be
> > able to inform the user via a popup dialog box and then quit my
> > application gracefully.
> 
> and how do you propose to gracefully recover from the absence of the
> whole user interface definition?  if such a thing happens in production
> if means you've screwed up the installation of the application so badly
> that you can't really trust anything to be working correctly - hence an
> abort() is the Right Thing(tm) to do; if this happens during a
> development cycle, then you'll be monitoring the standard error anyway,
> so whether gracefully presented to you or not, you're going to notice
> the error.

I dont think its right to assume what the builder will be used for,
that it will be currently parsing the main UI description, a random
dialog that might have been introduced by a semi-trustworthy plugin,
or a few serialized GObjects passed over an internet link.

My opinion is quite simply, if we dont crash when loading a jpeg,
we shouldnt crash when loading a glade file.

Cheers,
                 -Tristan