Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Re: Gtk2-Perl: Waiting for particular event

by moritz (Cardinal)
on Mar 23, 2013 at 18:15 UTC ( #1025056=note: print w/ replies, xml ) Need Help??


in reply to Gtk2-Perl: Waiting for particular event

On the code level this means that the application should wait within the _save_work() subroutine for a 'button-press' event and, when it was passed to either the "Ok"-button or the "Cancel"-button, the program should execute the necessary actions and leave the loop. If any other event will occur the application should stay in that loop to force the user to press one of the buttons.

Somehow "looping and waiting" makes me uneasy, because you are already in an event loop that is responsible for looping and waiting.

So another approach would be to have the code register a callback for the "Ok" and one for the "Cancel" button, disable most of the widgets, and then return.

Then the event handlers for the "Ok" and "Cancel" buttons are responsible for calling the callbacks that the code we first talked about registered.


Comment on Re: Gtk2-Perl: Waiting for particular event
Re^2: Gtk2-Perl: Waiting for particular event
by Bloehdian (Initiate) on Mar 23, 2013 at 21:13 UTC
    Hi moritz,

    > Somehow "looping and waiting" makes me uneasy, because you

    > are already in an event loop that is responsible for

    > looping and waiting.

    I was aware of the main loop issue, but I thought that this would be "healed" with the call to the Gtk->events_pending function. Isn't it like that?

    Not using the "waiting for event" approach would, at least, have the consequence not having a "closed" _save_work method any more, which does all the stuff, but several independent functions which would conceal the application's logic, i.e., this would make it harder to understand the code.

    So, I would like to stick to the "wait" approach if ever possible.

    Cheers

    Bloehdian

      Not using the "waiting for event" approach would, at least, have the consequence not having a "closed" _save_work method any more, which does all the stuff, but several independent functions which would conceal the application's logic, i.e., this would make it harder to understand the code.

      There's a reason one usually doesn't have one function which does "all the work". Afaict _save_work should just, well, save the work, not do UI teardown and other stuff. Doing one thing per function usually increases readability, not decreases it.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1025056]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (11)
As of 2014-09-17 11:02 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (72 votes), past polls