On Tue, 2003-09-02 at 13:58, Colin Fox wrote: > On Mon, 2003-09-01 at 20:09, Malcolm Tredinnick wrote: [...] > > For your standard GtkDialog widget, the only way the 'close' signal is > > emitted is when the Escape key is pressed. Widgets deriving from > > GtkDialog may have other buttons that are hooked up to emit 'close', but > > by default it is only bound to the Escape key (try it and see for the > > About dialog -- you can close it with Escape and it emits the predicted > > signal). > > > > So, in short, for something like the About dialog box: connect to > > 'response', hide the dialog box and then call the emit_stop_by_name() > > method. Connect to 'delete' and ignore it by returning gtk.TRUE. Ignore > > 'close' -- it is not useful in this case. > > > > Except, as you've pointed out, that it's used for the Escape key > handling. If you catch 'close', the escape key works. Otherwise it's > ignored. I like making it go away with an escape key, so I'll keep the > close handler.
Fair enough. The Escape key binding seems pretty non-intuitive to me for the About box (it's just a mysterious accelerator with no mouse equivalent), so I tend to ignore it. But your view has validity too. > > Does this clarify things? If not, please sing out, because my psychic > > abilities tell me that Christian may end up using his cut-and-paste > > buttons to drop portions into the FAQ (possibly as an extension to > > 10.6), so it would be good if it was vaguely understandable. > > Amazing - Jedi powers & psychic abilities. Who said programmers were > boring? :) > > Just to sum it up - this is what I needed in my program to make the > about box work completely (these handlers are part of a class): > > def on_aboutbox_response( self, dialog, arg1, *args ): > # system-defined GtkDialog responses are always negative, > # in which case we want to hide it > print "aboutbox_response" > if arg1 < 0: > dialog.hide() > dialog.emit_stop_by_name( 'response' ) > > def on_aboutbox_close(self, widget, event=None): > self.aboutbox.hide() > return gtk.TRUE > > def on_aboutbox_delete_event(self, widget, event=None): > self.aboutbox.hide() > return gtk.TRUE The self.aboutbox.hide() call is not strictly required in the delete-event handler. This is because if a GtkDialog receives a delete-event signal, it will emit a response signal (this is documented in the C language GTK API documentation and backed up by the C source code). So just preventing the further propogation of the delete-event signal should be sufficient (you can't ignore it or your widget gets destroyed which is what started us down this thread). Of course, leaving it in does no harm either, since calling hide() on an already hidden widget is fine. > Naturally, the 'close' and 'delete_event' signals could point at the > same handler. It's just useful to have them separate for debugging. > > I still think the response handler having to do an emit_stop_by_name() > is weird. Why can't I just hide it, like the other handlers? Because life sucks. :) Seriously, I do not know -- but all my own various attempts to do this other ways have failed (as well as other peoples' on this list), so I'm now walking the party line on this one. Cheers, Malcolm _______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
