NAME

Curses::UI::POE - A subclass makes Curses::UI POE Friendly.

SYNOPSIS

use Curses::UI::POE;

my $cui = new Curses::UI::POE inline_states => {
    _start => sub {
        $_[HEAP]->dialog("Hello!");
    },

    _stop => sub {
        $_[HEAP]->dialog("Good bye!");
    },
};

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

ADDITIONS

This is a list of distinct changes between the Curses::UI API, and the Curses::UI::POE API. They should all be non-obstructive additions only, keeping Curses::UI::POE a drop-in replacement for Curses::UI.

Constructor Options

inline_states

The inline_states constructor option allows insertion of inline states into the Curses::UI::POE controlling session. Since Curses::UI::POE is implimented with a small session I figured it may be useful provide the ability to the controlling session for all POE to Interface interaction.

While Curses::UI events are still seamlessly forced to use POE, this allows you to use it for a little bit more, such as catching responses from another POE component that should be directly connected with output. (See the IRC client example).

In this controlling session, however, the heap is predefined as the root Curses::UI object, which is a hash reference. In the Curses::UI object, all private data is indexed by a key begining with "-". So if you wish to use the heap to store other data, simply dont use the "-" hash index prefix to avoid conflicts.

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.

MAINTAINER

Scott McCoy (tag@cpan.org)

This was my stupid idea. I also got to maintain it, although the original code (some of which may or may not still exist) came from Rocco.