non-blocking delay in dialog emulation subclass

[zentara-2]

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(). Without the delay,
the Show() would return right away.
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?
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? :-)

This is just a basic idea, I've yet to work out setting input values, and
resetting. My main question is the use of the non-blocking delay to get
a response, the best way?

See attachment.

Thanks,
zentara


--
I'm not really a human, but I play one on earth.
http://zentara.net/CandyGram_for_Mongo.html 

_______________________________________________
gtk-perl-list mailing list
gtk-perl-list@...
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

[muppet]

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@...
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

[zentara-2]

On Wed, 16 Jul 2008 14:43:53 -0400 (EDT)
"muppet" <scott@...> 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?

>
>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.  

>
>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.

Hmmm, I don't get that part... I'll have to thinks. Ouch !!

Thanks
zentara

--
I'm not really a human, but I play one on earth.
http://zentara.net/CandyGram_for_Mongo.html 
_______________________________________________
gtk-perl-list mailing list
gtk-perl-list@...
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

[Matthew Braid-2]

Hi,

2008/7/17 zentara <zentara1@...>:
> On Wed, 16 Jul 2008 14:43:53 -0400 (EDT)
> 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.

Rather than making a whole new class of dialogs, I usually use a
wrapper package that does the work for me.

For instance, if I want a dialog that asks for a single line of input,
that package might have a sub like:

sub ask {
 my $self = shift;
 my ($question) = @_;
 my $dlg = Gtk2::Dialog->new(....);
 # Set up the dialog how you want. In this case we'd put a label and
an entry in.
 # The entry is important, so I'll keep that bit of code here
 my $ent = Gtk2::Entry->new;
 # Pack everything, and then ready to go
 my $res = $dlg->run;
 $dlg->hide;
 # If your 'get the result' section is a bit long, you might want to do a
 # Gtk2->main_iteration while (Gtk2->events_pending);
 # to make the dialog hide _now_
 if ($res eq 'ok') {
   $res = $ent->get_text;
 } else {
   $res = undef;
 }
 $dlg->destroy;
 return $res;
}

This package is normally called something like TOP::LEVEL::Dialog
(where TOP::LEVEL is the namespace my app is using), and then you can
just add subs like the above to do the work for you, instantiate that
package (with important details like the window to be modal on etc),
and then just do stuff like:

my $txt = $dialogs->ask("Enter planet to destroy: ");
if (defined($txt)) {...}

More complex dialogs might have their own callback package as well -
this method allows you to have dialogs as complex as you want that
return exactly the data you want without having to fill your main code
with all the 'build the dialog' details.

Oh, and I used to use a jerry-rigged version of Tk's waitVariable for
custom dialogs as well, but the whole $dlg->run thing is much better.

MB
_______________________________________________
gtk-perl-list mailing list
gtk-perl-list@...
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

[muppet]

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

> On Wed, 16 Jul 2008 14:43:53 -0400 (EDT)
> "muppet" <scott@...> 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


_______________________________________________
gtk-perl-list mailing list
gtk-perl-list@...
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

[zentara-2]

On Thu, 17 Jul 2008 08:13:11 +1000
"Matthew Braid" <ptkperl@...> wrote:


>my $txt = $dialogs->ask("Enter planet to destroy: ");
>if (defined($txt)) {...}

I see I have a security leak about my plan?  :-)

>More complex dialogs might have their own callback package as well -
>this method allows you to have dialogs as complex as you want that
>return exactly the data you want without having to fill your main code
>with all the 'build the dialog' details.
>
>Oh, and I used to use a jerry-rigged version of Tk's waitVariable for
>custom dialogs as well, but the whole $dlg->run thing is much better.
>
>MB

Thank you , Matthew and muppet, I've learned a big lesson and
this helps me take a nice step forward.

zentara

--
I'm not really a human, but I play one on earth.
http://zentara.net/CandyGram_for_Mongo.html 
_______________________________________________
gtk-perl-list mailing list
gtk-perl-list@...
http://mail.gnome.org/mailman/listinfo/gtk-perl-list