Re: [gtk-list] Window destroy prop with gtk--

[Tero Pulkkinen <terop students cc tut fi>]

Oliver Freyd <freyd@uni-muenster.de> writes:
> Now as I've upgraded to gtk+0.99.8 and gtk---0.7.18 I've found
> that without any delete event handler windows get destroyed when
> one clicks the delete button. Afterwards the object is gone and has to be
> recreated.

This is known problem. I just dont know what to do about it :( I think
there is some problems with the implementation gtk is using. (for
example the current default implementation in gtk leaves processes
running if apps are started with ./fooapp & and when last window of the
application is closed.. => very bad thing)

> If you have a dialog like the file selection, you would have to inherit
> it by a new class to add a virtual delete_event_impl, so that's a bit awful.
> 
> I used to connct a function to delete_event, that just hide()s the window,
> so when you recreate it it's simply shown again. But now that doesn't seem to
> work, even tried returning true or false, no difference.

I think true and false should do different things in these cases. I
have suspected the return type handling in gtk-- does not always work
correctly - it has been too rarely used... I'll fix this after the next
larger change is finished(splitting the gtk-- to tiny files). Before that,
override the virtual function :(

> BTW, try  the example "testme" from gtk--, push the button to open the
> fileselector, then destroy it. If you push the button again, you get the error
> messages:
> 
> ** WARNING **: file gtksignal.c: line 299 (gtk_signal_lookup): "gtk_type_is_a
> (object_type, GTK_TYPE_OBJECT)"
> 
> ** WARNING **: gtk_signal_emit_by_name(): could not find signal "show" in the
> `(null)' class ancestry 

this looks odd.. I'll have to investigate this when the large change
is finished..

-- 
-- Tero Pulkkinen -- terop@modeemi.cs.tut.fi --