Re: Gtk::Window should not auto-destruct



On Sat, 2001-11-10 at 18:34, Tim Janik wrote:
> On 7 Nov 2001, Murray Cumming wrote:
> 
> > In gtkmm-1.2, Gtk::Window self-destructs when the window manager's close
> > button is clicked, unless you return TRUE from a delete_event signal
> > handler. This is described here:
> > http://developer.gnome.org/doc/GGAD/z207.html
> > 
> > This is silly. Unusual memory management should not be the default. I
> > plan to change this in gtkmm-1.3, as I did for Gnome::Dialog in gnomemm.
> > I will add a Gtk::Window::set_destroy_on_delete_event_() method for
> > temporary compatibility.
> > 
> > Instead, you should just connect to the Gtk::Wdget::hide signal,
> > inherited by Gtk::Window, and do whatever you want then. This allows you
> > to reshow a window later, or destroy it, or quit the whole program.
> > 
> > Wonder why you never knew this before? Because on_delete_event() was
> > called delete_event_impl(). And because we mistakenly used the useless
> > "destroy_event" signal in some of our examples instead. We don't wrap
> > "destroy_event" anymore.
> 
> please, do _not_ do this.
> grep for delete_event in gtk's changelog, we've been through this hassle.
> iirc, we changed the gtk behaviour to default destroy a window or not
> upon delete event 4 or 5 times (one change to not auto-destroy windows
> lasting for about half a year or so). the main problem with not honouring
> delete event is that most programmers do not (want to) setup an explicit
> handler for this, which leaves the user with an unusable delete button
> on his window decoration frame.

Sorry, I had no idea that I'd sent this to gtk-devel-list instead of
gtkmm-main.

We are currently thinking about the best solution for this. Our solution
for most cases is to specify one window as the main app window, like so:

Gtk::main::run(window);
The main event loop will then stop when that main window is closed.

The main problem is that returning TRUE seems to stop any other signal
handler from being called, thus stopping anybody else from handling that
signal.

-- 
Murray Cumming
murrayc usa net
www.murrayc.com




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