Re: [gtk-list] Re: Bug in fileselection [0.99.3] ?
- From: Tim Janik <Tim Janik Hamburg Netsurf DE>
- To: gtk-list redhat com
- Subject: Re: [gtk-list] Re: Bug in fileselection [0.99.3] ?
- Date: Mon, 2 Feb 1998 20:23:26 +0100 (CET)
On 2 Feb 1998, Owen Taylor wrote:
> Nils Philippsen <nils@rhlx01.rz.fht-esslingen.de> 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 <timj@gimp.org>
[ 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.
dito!
>
> Regards,
> Owen
---
ciaoTJ
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]