poe::loop::tk(3pm) [debian man page]

POE::Loop::Tk(3pm)					User Contributed Perl Documentation					POE::Loop::Tk(3pm)

sub skip_tests {
  return "Tk needs a DISPLAY (set one today, okay?)" unless (
    (defined $ENV{DISPLAY} and length $ENV{DISPLAY}) or $^O eq "MSWin32"
  );
  my $test_name = shift;
  if ($test_name eq "k_signals_rerun" and $^O eq "MSWin32") {
    return "This test crashes Perl when run with Tk on $^O";
  }
  return "Tk tests require the Tk module" if do { eval "use Tk"; $@ };
  my $m = eval { Tk::MainWindow->new() };
  if ($@) {
    my $why = $@;
    $why =~ s/ at .*//;
    return "Tk couldn't be initialized: $why";
  }
  return; }

NAME

       POE::Loop::Tk - a bridge that allows POE to be driven by Tk

SYNOPSIS

       See POE::Loop.

DESCRIPTION

       POE::Loop::Tk implements the interface documented in POE::Loop.	Therefore it has no documentation of its own.  Please see POE::Loop for
       more details.

       POE::Loop::Tk is one of two versions of the Tk event loop bridge.  The other, POE::Loop::TkActiveState accommodates behavior differences in
       ActiveState's build of Tk.  Both versions share common code in POE::Loop::TkCommon.  POE::Loop::Tk dynamically selects the appropriate
       bridge code based on the runtime environment.

SEE ALSO

       POE, POE::Loop, Tk, POE::Loop::TkCommon, POE::Loop::PerlSignals.

AUTHORS &; LICENSING
       Please see POE for more information about authors, contributors, and POE's licensing.

perl v5.10.1							    2010-04-11							POE::Loop::Tk(3pm)

POE::Resource(3pm)					User Contributed Perl Documentation					POE::Resource(3pm)

NAME

       POE::Resource - internal resource managers for POE::Kernel

SYNOPSIS

       Varies, although most POE::Resource subclasses do not have public APIs.

DESCRIPTION

       POE manages several types of information internally.  Its Resource classes are mix-ins designed to manage those types of information behind
       tidy, mostly private interfaces.  This was done to facilitate testing and a conversion to C without the need to port POE::Kernel all at
       once.

       POE::Resource subclasses are generally different from one another, but there are some similarities to note.

       Every resource should have an initializer and finalizer method.	Initializers set up initial data and link resources into POE::Kernel.
       Finalizers clean up any remaining data and verify that each resource subsystem was left in a consistent state.

       One common theme in resource implementations is that they don't need to perform much error checking, if any.  Resource methods are used
       internally by POE::Kernel and/or POE::API classes, so it's up to them to ensure correct usage.

       Resource methods follow the naming convention _data_???_activity, where ??? is an abbreviation for the type of resource it belongs to:

	 POE::Resource::Events	    _data_ev_initialize
	 POE::Resource::FileHandles _data_handle_initialize
	 POE::Resource::Signals     _data_sig_initialize

       Finalizer methods end in "_finalize".

	 _data_ev_finalize
	 _data_handle_finalize
	 _data_sig_finalize

       Finalizers return true if a resource shut down cleanly, or false if there were inconsistencies or leaks during end-of-run checking.  The
       t/res/*.t tests rely on these return values.

SEE ALSO

       POE::Resource::Aliases, POE::Resource::Events, POE::Resource::Extrefs, POE::Resource::FileHandles, POE::Resource::SIDs,
       POE::Resource::Sessions, POE::Resource::Signals

       Also see "Resources" in POE::Kernel for for public information about POE resources.

BUGS

       None known.

AUTHORS &; LICENSING
       Please see POE for more information about its authors, contributors, and licensing.

perl v5.14.2							    2012-05-15							POE::Resource(3pm)