Re: GNOME GTK-- Projects

[John R Sheets <dusk smsi-roman com>]

Erik Andersen wrote:
> And of course, Gtk-- _still_ has the stupid menufactory
> bug which means you cant hook anything up to the menus you create other
> then argumentless callbacks (which still give a warning)...  And there is no
> exception handling in gtk--.  So for instance if you do something like:
> 
>         char* szMsg[]="Some Text";
>         Gtk_Text myTextObject;
>         // Should call realize first to avoid error, since you can't
>         // put text into an un-realized text widget.
> 
>         // Don't do it here which will cause an error
>         // myTextObject.realize();
> 
>         myTextObject.insert(NULL, NULL, NULL, szMsg, sizeof(szMsg) );

Would it be practical to add a quick (boolean) check to the
Gtk_Text (or whichever objects need it) to see if the object has
been realized yet, and to auto-realize it if the code tries to
insert text into an un-realized object?  For example,

Gtk_Text::insert (...)
{
   if (!bRealized)
   {
      realize();
      bRealized = TRUE; // or put this in realize()
   }

   [...]
}

I mean, granted, you could say that this might make gtk-- users
sloppier, and not know when their objects need realizing (is
there ever a case when you wouldn't want to call
Gtk_Text::realize()?)...but it would make apps a little more
robust and consistent.  And isn't that one of the principles of
OO, that your objects should know how to take care of
themselves?  The fewer function calls I have to make for each
object, the fewer mistakes I will end up making in the long run,
especially if I'm repeating the same calls over & over...

> the underlying Gtk+ function will complain to stderr using g_warning,
> but there is absolutly no way for your application program to know
> that something bad happened and do something intelligent.  It would
> be nice to wrap stuff like this with:
> 
> try {
> ...
> }
> catch (GTTKMM_Exception error) {
>         // Handle things
> }
> 
> but there doesn't seem to be any way to implement this, since Gtk+ doesn't
> seem to report errors anywhere except to stderr (i.e. no customizable error
> handler function) to do this...  Really unfortunate...  

I'm definitely a fan of exception handling.  Granted, I'm
somewhat new to the UNIX end of things, but would there be any
way to write a class to attach to stderr and parse its output,
looking for errors?  Or is GTK+ consistent enough in its
reporting formats to make this feasible?  Perhaps a virtual
exception scheme would be possible, where a GTK+ error string
would trigger an exception throw that GTK-- could pick up?  I
don't know.  I'm just tossing ideas out like playing cards right
now...

Tero Pulkkinen wrote:
> Damn, This is a good idea. Maybe we can get support for this to
> gtk1.1, if it does not exists already in gtk. It does take a long time
> until we can really use it to do applications(1.0 gtk will be standard
> for a LONG time), but better late than never. (well, thank god
> compilers have poor support for exceptions too, so we cannot really
> use it yet either - or at least there needs to be way to disable it..)

Do you mean that we can't really use full exception handling
because of the compilers, so it's almost a moot point anyway? 
And by "disable it" do you mean disable exception handling in
case someone tries to use gtk-- with a compiler that has NO
exception support?  

John