On Tue, 2003-09-02 at 04:59, Colin Fox wrote: [...] > Hmm. I put this in: > > def on_aboutbox_response( dialog, arg1, *args ): > if arg1 < 0: > dialog.hide() > dialog.emit_stop_by_name( 'response' ) > > This causes it to work properly if the user clicks the "Ok" button, but > it's a hack. Why should you have to force a signal to be stopped just > because you're using an about box? I don't think the old versions of the > library required such contortions... Regardless, if the user clicks the > close box, it will still crash when you try to re-invoke it. > > I'm catching the close signal, and it NEVER gets sent. That seems to be > a bug, too. Same with the delete event. The ONLY event sent by the about > box is 'response'.
OK, pretend I am waving my hand in a Jedi-like fashion and saying "There is no problem here". Convinced? I'm not kidding ... everything is working normally. If you are still reading this, my powers are weaker than I thought, so here is an explanation of what is going on... A GtkDialog box has two main signals it implements: 'close' and 'response'. It also inherits the 'delete-event' signal from the GtkWidget class which also has a role to play here. The 'response' signal is emitted pretty much whenever any action happens that causes the dialog box to finish running. The response signal emission will contain a "response ID" which can be user-defined or any one of the gtk.RESPONSE_* constants in pyGTK. The standard values correspond to things like one of the standard buttons being pushed or the window being destroyed. You can act differently based on the response ID. The 'delete' signal is emitted whenever the corresponding GtkWidget is deleted in a "strange" (for want of a better word) way. The main case here is when the user closes the window via the window manager (Alt-F4, or clicking on the 'X' button in a typical window manager, for example). In that case, you also get a 'response' signal, so generally you just ignore the 'delete' signal (return gtk.TRUE as has been mentioned elsewhere). 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. 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. 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/
