Re: dialog close signal and hiding dialog...

[Matthew Weier OPhinney <matthew-lists weierophinney net>]

-- Ross McFarland <rwmcfa1 neces com> wrote
(on Tuesday, 12 August 2003, 08:22 PM -0400):
> On Tue, 2003-08-12 at 19:48, Matthew Weier OPhinney wrote:
> > Okay, I figured out what I needed to do. The dialog is actually being
> > called as part of another class, something like this:
<snip code example>
> > ($dialog->dialog is the actual GtkDialog object). As you can see, I'm
> > destroying the entire object I've created; it then gets recreated next
> > time I need the dialog. I'd _prefer_ to be able to keep it around for
> > later (as I'm able to do when I click the 'Ok' button and do a
> > $dialog->hide); however, this works, and I no longer get the
> > segmentation faults.
>
> according to this:
> http://developer.gnome.org/doc/API/2.0/gtk/GtkDialog.html#gtk-dialog-run
>
> the default behavior (destroying) of the delete event is blocked while
> in a gtk_dialog_run call. instead the response GTK_RESPONSE_DELETE_EVENT
> (delete-event) is returned and it is up to the programmer to destroy or
> (in your case) hide the widget. it would then exist the next time you
> come around to run it as you want. i'm pretty sure that i've relied on
> that behavior in the past. 
>
> i see you have $dialog->show that is a method of ROX, but in that show
> do you call run. what you are describing sounds like you're calling show
> and trying to handle the signals yourself. 

Yeah, that's what I'm trying to do... which I think may be the
problem...

> with a Gtk2::Dialog you should do something like the following
>
> my $dialog = new Gtk2::Dialog(...);
>
> # blocks until the button is clicked
> # returns which one
> $resp = $dialog->run; 
> if( $resp eq 'ok' )
> {
>       # save the settings
> }
> else # ( $resp eq 'revert' ) 
> {
>       # revert to old settings

What happens here, though, in terms of keeping the dialog shown? Hmmm...
thinking I may be using the wrong widget...

>       # notice that delete-event would have fallen in here too
>       # thus given the expected behavior that if they click the 
>       # X to close the window they probably didn't want to
>       # save the changes.
> }
>
> in most cases you should not have any signals connected to your dialog.
> that's the beauty and purpose of it. if you're connecting your own
> signals then you're probably not using it as it was intended.

Indeed, I think I'm tackling it wrong, though I've got it working.

I'm actually translating a pygtk-based library (ROX-Lib2) to perl using
gtk2-perl, and I've noticed a *TON* of differences in how the pygtk API
works vs. the gtk2 C api -- which, I'm happy to report, gtk2-perl
follows very closely, making looking at the C api very worthwhile for
gtk2-perl programmers. 

Long and short of it, I think this is one area where the pygtk ->
gtk2-perl direct conversion isn't making sense. The window is a 'dialog'
in name only; in function, it's a very complex window with a lot of
signals being emitted. I think I'll probably change this to be a
GtkWindow with a GtkVBox once I get a few issues ironed out.

Thanks for your explanations of how the GtkDialog is supposed to work;
very informative, and I'll keep it in mind for the future!

-- 
Matthew Weier O'Phinney
http://weierophinney.net/matthew/