Re: non-blocking delay in dialog emulation subclass

["muppet" <scott asofyet org>]

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>