Re: non-blocking delay in dialog emulation subclass

[muppet <scott asofyet org>]

On Jul 16, 2008, at 4:01 PM, zentara wrote:

> On Wed, 16 Jul 2008 14:43:53 -0400 (EDT)
> "muppet" <scott asofyet org> wrote:
>
> > 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?
> For the rgba?  Can a regular window have an rgba background?

Ah, missed that.  Doesn't explain the other three, though.  ;-)


> > 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.
>
> Well the idea is not just for color. I'm looking for a general purpose
> popup that returns whatever I want, instead of integers(like a  
> dialog).
> I might want a textbox, or entries, etc.

This is akin to what i used to use for just this purpose:

    sub get_string {
        my ($title, $parent, $prompt, $initial_value,  
$default_cancel) = @_;

        my $dialog = Gtk2::Dialog->new ($title, $parent, [],
                                        'gtk-cancel' => 'cancel',
                                        'gtk-ok' => 'accept');

        my $label = Gtk2::Label->new ($prompt || '');
        $dialog->vbox->add ($label);
        $label->show ();

        my $entry = Gtk2::Entry->new ();
        $entry->set_text ($initial_value) if defined $initial_value;
        $dialog->vbox->add ($entry);
        $entry->show ();

        $dialog->set_default_response ($default_ok ? 'accept' :  
'cancel');

        my $ret;
        if ('accept' eq $dialog->run ()) {
            $ret = $entry->get_text ();
        }
        $dialog->destroy ();

        return $ret;
    }


> > > 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.
>
> Hmmm, I don't get that part... I'll have to thinks. Ouch !!

There are a variety of technical problems with using a timer to poll  
for the user's input, not the least of which being the possibilities  
for duplicate button presses and the latency vs load issues involved.

By "even if you have to create your own signal to decouple", i'm  
referring to how to design the classes and interactions such that you  
don't tie things together in a way that leaves you stuck.  In  
GtkDialog, you don't connect directly to the "clicked" signals on the  
dialog's action buttons, you connect to the "response" signal on the  
dialog; the dialog creates the buttons for you, and connects to the  
"clicked" signal on each one, and emits "response" instead.  This  
extra signal insulates you, the user of the GtkDialog, from how the  
insides actually work, and from changes to which buttons exist or how  
they are created.


--
I hate to break it to you, but magic data pixies don't exist.
  -- Simon Cozens