NAME

Curses::UI::POE

SYNOPSIS

use Curses::UI::POE;
my $cui = new Curses::UI::POE;
$cui->mainloop

INTRODUCTION

This is a subclass for Curses::UI that enables it to work with POE. It is designed to simply slide over Curses::UI. Keeping the API the same and simply forcing Curses::UI to do all of its event handling via POE, instead of internal to itself. This allows you to use POE behind the scenes for things like networking clients, without Curses::UI breaking your programs' functionality.

TIMERS

The undocumented Curses::UI timers ($cui->timer) will still work, and they will be translated into POE delays. I would suggest not using them, however, as POE's internal alarms and delays are far more robust.

DIALOGS

The Curses::UI::POE dialog methods contain thier own miniature event loop, similar to the way Curses::UI's dialog methods worked. However instead of blocking and polling on readkeys, it incites its own custom miniature POE Event loop until the dialog has completed, and then its result is returned as per the Curses::UI specifications.

MODALITY

Curses::UI::POE builds its own internal modality structure. This allows Curses::UI to manage it, and POE to issue the (hopefully correct) events. To do this it uses its own custom (smaller) event loop, which is reentrant into the POE::Loop in use (In this case, usually POE::Loop::Select). This way there can be several recursed layers of event loops, forcing focus on the current modal widget, without stopping other POE::Sessions from running.

SEE ALSO

POE, Curses::UI. Use of this module requires understanding of both the Curses::UI widget set and the POE Framework.

BUGS

None Known. Whoohoo!

Find any? Send them to me! tag@cpan.org

AUTHOR

Rocco Caputo (rcaputo@cpan.org)

Rocco has helped in an astronomical number of ways. He helped me work out a number of issues (including how to do this in the first place) and atleast half the code if not more came from his fingertips.

Scott McCoy (tag@cpan.org)

This was my stupid idea. Its working out quite well though.