Main index > Perl programming > Understanding event handling?

By damien (User), on Wed Jan 10 17:31:19 2007: Understanding event handling?.

Hi.
I read over and over the lines in all the python scripts, and this in the info pages:

Quote:


Commands have been wrapped into Python functions, and an `Events_handler' class has been made public to handle asynchronous feedback from the interpreter.


Is there a similar class for perl? The example in the adesklets.pm module shows a hash of subroutines(?) as event handlers...er..I'm showing my lack of knowledge here...

More succinctly, can I 'poll' for events? How do I keep the adesklets::event_loop from blocking? Is this what event_catch and event_uncatch are for?

Any insight would be immensely appreciated.

By syfou (Core Developer & Desklet Author), on Wed Jan 10 20:01:49 2007.

A short explanation about events handling in Perl can be found in the "Programming adesklets" chapter from the adesklets documentation (also available as a texinfo manual). A working example is also provided within the package (See test/test.pl).

In most cases. you won't need to play with the various event-related functions of the interpreter (event_catch, events_get_send_sigusr1, events_reset_all, event_uncatch, events_info, events_set_echo, events_get_echo, events_purge, and events_set_send_sigusr1), since events_loop() will cover most of the use cases you will meet (but if you ever do, have a look at the adesklets.pm source and on the "Using adesklets from other language environments" chapter for a complete explanation). Yours,

By damien (User), on Wed Jan 10 20:48:53 2007.

Thanks for the response..
I was having trouble understanding how to include my batch-like code in an event loop (first time for everything :roll: )

...but simply wrapping the LeaveNotify callback around it works.

Code:


adesklets::event_loop(LeaveNotify=>\&keep_scrolling);



I have done some event-oriented programming before, but it involved polling for events and then dropping me back to the flow, rather than staying infinitely in the loop. New stuff to me! Maybe it'll help somebody else along the way.

By damien (User), on Thu Jan 11 19:54:23 2007, last edited on Fri Jan 12 19:23:15 2007.

...addendum. That actually doesn't work.
(Notes of a Novice follow!)

I'm looking to create a constantly repeating loop of text_draw commands that is also simultaneously polling for events. There looks to be two ways of accomplishing this, (1) with the use of adesklets' record/playback function and (2) with perl's fork().

The reason that simply adding the (loop that I hope to have repeat endlessly) into the LeaveNotify callback doesn't work: once the loop makes it's way through once it returns to the event handler and there's nothing on the queue to 'handle'. I even tried adding an adesklets::send_command(event_catch,"LeaveNotify") to the end of my loop, hoping that it would cause the event handler to simply push back into the loop if there were no other waiting events.(the assumption being that this command would add a LeaveNotify to the queue). This is no solution. No interactivity is possible during the subroutine anyhow, so you'd have to wait until the entire scrolling sequence finished before it would notice your keypresses.

I'm still working on understanding the record/playback function. It'd take some serious reformulating of the way my little applet works to use that feature, since currently the title print/scroll subroutine takes advantage of a lot of perl stuff.

adesklets is a WONDERFUL learning tool!!! THANK YOU

edit: After your post that follows, I saw how my wording confused things. I changed what is in red. :?

By syfou (Core Developer & Desklet Author), on Fri Jan 12 02:50:22 2007.

Hi damien,

I am not 100% sure what you are trying to achieve... A few facts first: What I understand is that you are trying to find a way to combine periodic actions with events pooling; this snippet should give you a good starting point: In most cases, You will not need to fork other process to handle periodic actions (because they are short)... But it is true that in the case of a feed handler, it might be better design to have a separate thread (or process) to asynchronously fetch the data, while the parsing is performed through timed actions. Hope this helps,

By damien (User), on Fri Jan 12 18:14:54 2007.

Yes! It helped so much it's going to take me a few days to understand it all.

If this works the way I perceive it to, it's precisely what I was trying to accomplish. Instead of using the stock event_loop, you've rewritten one that includes a 'tic', is that correct? Now instead of


Code:


# (from adesklets.pm)
sub event_loop
{
    my %functionhash = @_;
    foreach (keys %functionhash) 
        { adesklets::send_command("event_catch",$_); }
    #.....



...you've got:

Code:


 sub my_event_loop
 {
     my $tic          = shift(@_);
     my %functionhash = @_;
     #.....



NICE. :D
Well, I have some more studying to do!


adesklets is proud to be hosted on:

SourceForge.net Logo

Back to adesklets.sf.net.