Re: [gtk-list] Re: Bug in fileselection [0.99.3] ?

On 2 Feb 1998, Owen Taylor wrote:

> Nils Philippsen <> writes:
> > On 2 Feb 1998, Preben Randhol wrote:
> > 
> > > 
> > > I took out the code from the testgtk.c modified it so that when
> > > choosing a file the fileselection window was destroyed (calling
> > > gtk_detroy_widget(fileselectionwindow) from the callback function
> > > of the Ok button). This works fine if you choose a file and then press
> > > the Ok button. If you however double click on a file the whole program
> > > crashes with a BadWindow error or some such. 
> > 
> > I experienced this since 0.99.0. It's easy to fix - if you know how. Just
> > connect "destroy" of the file selection to the function you connected to the
> > Cancel button and you should be happy again. BTW: I think this should be done
> > by default - It has been working up to gtk+-971201 without connecting
> > "destroy", so why doesn't it do this way since 0.99.0? Owen? <- Let's see if
> > this draws attention :-)
> I don't know what was wrong with 0.99.3, exactly, but I found quite
> a few problems with the current CVS:
>  - The FileSelection "destroy" handler wasn't multiply callable
>    (only a temporary problem, but was hiding the other problems)
>  - CList didn't properly gdk_window_set_data (window, NULL) all its
>    windows, so it could get events on them after it was
>    destroyed/finalized!

one of the enforcements through out the code that still have to be
attacked ;)
BTW: i think we can savely ignore events with event_widget == NULL, now,
since marius had the checks for this in his patch, and told me he
expects destroyed pixmaps to send bogus expose events with window==NULL.

> and, most importantly
>  - gtk_widget_propagate didn't ref count properly.
> After fixing all of those, things seem to work fine.

oops ;)
seems i got around commiting this faster than you did ;)
from the last CHangeLog entry:

Mon Feb  2 04:15:08 1998  Tim Janik  <>
[ i din't do this at 4 o'clock it's just that emacs adds a new entry
  once a new day has begun ,)]

        * gtk/gtkmain.c (gtk_propagate_event): fixed a bad, bad referencing
          bug that could caused unreferencing of finalized objects.

        * gtk/testgtk.c: destroy fileselection on "OK" (this triggered the
          above mentioned bug).

        * gtk/gtkwidget.h:
        * gtk/gtkwidget.c:
        * gtk/gtkobject.h:
        * gtk/gtkobject.c:
          implemented and object reference tracer (gtk_trace_referencing) which
          is activated if GTK_TRACE_OBJECTS is defined (currently per default).
          in gdb: set the static variable `gtk_trace_object' to point to the
          object that you want to have reference traced.

        * gtk/gtkfileselection.c: few cleanups.

> > My advice to all having weird problems with gtk programming: Keep a copy of
> > the gimp source somewhere on the box, if you're in trouble see how it's
> > handled there, it saved me a lot of time (and nerves)
> Hmmm. Well, that may only make sure that bugs that aren't exposed
> by the GIMP, aren't exposed elsewhere. If you are having a weird
> problem, post it here (preferably with a small test case) and 
> hopefully we can either fix it, or explain why it isn't really
> that weird.
> > > 
> > > I also tested the code with gtk+-971025 and it worked there, no
> > > errors.
> > 
> > Yes. I still do not know if I should consider this as a bug or a feature...
> Very much a bug.


> Regards,
>                                         Owen


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]