NAME
    UI::All - Common Perl interface to the multitudinous GUI toolkits.

SYNOPSIS
      use UI::All;
      my $mw     = UI::All->MainWindow(title => "Run 1");
      my $vbox   = $mw->LayoutVBox;
      my $label  = $vbox->Label( text    => 'Hello, world!');
      my $button = $vbox->Button(text    => 'Quit',
                                 clicked => sub { $mw->exit_loop },
                                 );
      $mw->main_loop;
      exit;

      # OR #
      my $mw   = UI->MainWindow(title => "Run 2");
      my $vbox = $mw->LayoutVBox;
      $vbox->Label( text    => 'Hello, world (2)!');
      $vbox->Button(text    => 'Quit',
                    clicked => [$mw => 'exit_loop'],
                    );
      $mw->main_loop;
      exit;

      # OR #
      my $mw = UI->MainWindow(title => "Run 3");
      $mw->Label( text    => 'Hello, world (3)!');
      $mw->Button(text    => 'Quit',
                  clicked => [exit_loop => $mw]);
      $mw->main_loop;
      exit;

DESCRIPTION
    Perl UI is a unified interface to many of the different GUI (and
    non-GUI) tool kits used for creating User Interfaces. The goal is that
    rather than learning each of the different tool kit interfaces, a
    developer can learn the Perl UI interface which will let them code once,
    and then use their application on multiple platforms with any of the
    available toolkits.

    Perl UI's API is derived from all of the toolkits. Much of the widget
    heirarchy is based upon Qt. The calling syntax is close to Tk.

FAQ
    Well this is more of an AQ than an FAQ because I don't know if the Q's
    are really all that frequent. But we'll try and nip them in the bud.

    Don't we already have graphical toolkits?
        Yes we do. There is Gtk, Gtk2, Qt2, Qt3, Win32 GUI, Tk and Wx perl.
        Oh and there are Curses UI, the Term:: package line, SDL, and
        others. Each of these work on various platforms. Each of these have
        their own API (and rightly so as each of the graphical toolkits try
        to follow the API of their compiled counterparts.

        We're not really interested in creating yet another Toolkit (well we
        sort of are with SDL). We want to write an application once, and
        have it appear native under Windows, under KDE or Gnome, under OSX,
        and if there are no graphical components (pixmaps or canvases) we
        wouldn't mind if it would work in the console.

    You did this in Perl? Why not Python, Ruby (your language here) ?
        I know perl fairly well. I don't know python, ruby, (your language
        here) - or at least not to an extent that I feel comfortable with.

    So why not do it in another language?
        I would love it if somebody did.

        Python has very good support and interface for most of the toolkits
        that Perl UI covers. It would be a great candidate for doing the
        same thing.

    Why Perl 5 ? Won't Perl 6 make it easier to implement ?
        (Ok - this one was a ringer) We have Perl 5 now. Perl 6 will be here
        relatively soon. I plan on doing the same thing for Perl 6. However,
        after Perl 6 comes out, there will still need to be work to
        interface the various graphical toolkits again. The difference this
        time is that Perl 6 will be able to interface directly with the core
        libraries in a more efficient way than Perl 5 is able to.

        A great benefit is that once this is done, then python or ruby on
        parrot will have access to the same library.

    GUI toolkits have huge API's - isn't this a large undertaking?
        Well - yes they are and yes this is. Contributors and members of the
        project are certainly welcome and are encouraged to join.

    Don't you have a long way to go ?
        Yes. Hence the low version number.

    You don't have (your widget name here) widget done yet. Where is it ?
        Requests are fine and welcome. We will move along with each widget
        once we have a mostly suitable widget in the toolkits that support
        it.

CLASSES
    Widgets and layouts are created by calling their class name as a method.
    Just about any object type can instantiate any other object type. This
    is done so that parent child relationships can be automatically assumed.
    For example:

      my $mw = UI::All->MainWindow; # typically only MainWindows are created by UI::All

      my $vbox = $mw->LayoutVBox;

      my $hbox = $vbox->LayoutHBox;

      my $lab1 = $vbox->Label( text => "Label1" );
      my $lab2 = $hbox->Label( text => "Label2" );
      my $lab3 = $hbox->Label( text => "Label3" );

      $mw->main_loop;

    The currently supported classes are as follows (supported signals and
    properties are listed - more will be added to the list as soon as they
    are reasonably supported in most toolkits):

    MainWindow
        The main widget used for display.

    TODO - finish the list

TIMELINE
        Approximate order of priority

        Preview Release (Proof of Concept)
                MainWindow
                LayoutVBox
                LayoutHBox
                TextEdit
                LineEdit
                Button
                FileDialog
                ListBox

        Initial Release
                Table  - Basic
                Canvas - Basic
                ProgressDialog
                MessageDialog
                RadioButton
                CheckBox
                ComboBox
                Slider
                Toolbar
                Menubar
                Actions
                Pixmaps

        More basic widgets
        Better Canvas Support
        More Widgets / Improved widgets
                TreeView
                ListView
                IconView
                ColorBox
                ColorDialog

        Network Support
        Better Asyncronous File IO support
        More standard dialogs
        System Tray support

BUGS
        * It isn't very easy to subclass a UI::All widget. This is because
        any subclassing really ought to provide functionality in all of the
        toolkits. This isn't really a fixable bug. I'm sure it will annoy
        more than one person.

        * It is heavy. The system uses a double matched heirarchy object
        system. It does it best to be simple - but probably fails. It would
        be better to just right a "light" wrapper around each toolkit.

        * Curses::UI is hard to work with. A more graceful failing toolkit
        will be created.

AUTHOR
        Paul Seamons - <perl-ui@seamons.com>

        Hopefully Others

LICENSE
        Distributed under the Perl Artistic License without warranty.

        Ok it isn't quite that easy. Perl UI supports the GPL. Depending
        upon the toolkit used then the Artistic can be applied as well.

        For example, Qt probably won't play nicely with the Artistic.

        We will probably build in an API that allows for express disabling
        of various toolkits for license reasons.

