zentara wrote: > Hi, > The general idea is to make a Dialog type widget, that returns > data instead of predefined button values, as a Dialog does it. > > So I used a non-blocking delay ( shown to me by muppet :-) ), > to make a window stay open during a Show().
Hey, don't blame that on me! ;-) > Without the delay, > the Show() would return right away. Okay, several comments: - Why are you reinventing Gtk2::Dialog? - Why are you reinventing Gtk2::ColorSelection? - Why are you reinventing Gtk2::ColorSelectionDialog? - Why are you using a canvas to get colored text? If what you want is something that returns you a color string after user interaction, you can have that with a trivial wrapper function in about ten lines. The trick is the recursive main loop, as you implemented in non_blocking_delay(). gtk_dialog_run() uses that same pattern to wait for the response signal on the dialog object. > In Perl/Tk, there is a waitVariable method, that will wait at that > point( non-blocking) until a variable changed. This is an attempt to > simulate that behavior. > Is this the best way to do this? Does Glib have something similar > to waitVariable? Glib does not, but somebody posted to this very list rather a long time ago an interesting experiment with tie() that got similar effects. > Anyways, I would appreciate any improvements. The way it works, > is during the Show() sub, the window will wait until a button > is pressed, then return a hex string if the button was Ok. > Bad or Good? :-) What you've done is Bad. You're using a recursive main loop to block control flow without blocking the main loop --- that part is okay. But don't use a timer to wait for user interaction in your recursive main loop; connect directly to the signal, even if you have to create your own signal to decouple. -- muppet <scott at asofyet dot org> _______________________________________________ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
