On Mon, 2003-09-01 at 20:09, Malcolm Tredinnick wrote: > > 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.
Cool! Being a gnome developer gives you Jedi powers!
> If you are still reading this, my powers are weaker than I thought, so
> here is an explanation of what is going on...
Your explanation is quite clear. Thank you!
> 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.
> 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
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?
Regards,
cf
--
Colin Fox <[EMAIL PROTECTED]>
CF Consulting Inc.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
