- CLASS HIERACHY
Tk - An Object Oriented Tk4.0 Extension for perl5
use Tk; $main = MainWindow->new(); $widget = $main->Widget(...); $widget->pack(...); MainLoop;
In writing the perl Tk extension, the goals were to provide a complete interface to the latest version of John Ousterhout's Tk, while providing an Object Oriented interface to perl code.
The package is composed of three loosely connected parts:
- pTk - Converted Tk source
The pTk sub-directory is a copy of the C code of Tk4.0, modified to allow use by languages other than the original TCL. (The pTk can be read as 'perl' Tk or 'portable' Tk depending on who your sensibilities.)
Tkto Perl "Glue"
The top level directory provides Tk.xs and nIO.xs and tkGlue.c which provide the perl-callable interfaces to pTk
- Perl code for "Widget" Classes
The Tk/Tk sub-directory contains the various perl modules that comprise the "Classes" that are visible to Tk applications.
The "major" widgets such as
Tk::Textare actually in separate directories at the top level (e.g. Text/* for
Tk::Text) and are dynamically loaded as needed on platforms which support perl5's
All the "command names" documented in Tcl/Tk are made to look like perl sub's and reside in the Tk package. Their names are all lower case. Typically there are very few commands at this level which are called directly by applications.
There are no actual objects of the
Tk::Widget class; however all the various Tk window "widgets" inherit from it, and it in turn inherits all the core Tk functions from Tk.
Tk::Widget provides various functions and interfaces which are common to all Widgets.
A widget is represent to perl as a blessed reference to a hash. There are some members of the hash which are private to Tk and its tkGlue code. Keys starting with
'.' and of the form
/_[A-Z][A-Za-z_]+_/ (i.e. starting and ending in _ and with first char after _ being upper case) should be condsidered reserved to Tk.
There is one class for each of the "Tk" widget item types. Some of them like
Tk::Frame do very little indeed, and really only exist so that they can be derived from or so that focus or menu traversal can discover the "kind" of window being processed.
Tk::Text for example, provide a lot of methods used with Tk's "bind" to provide a rich keyboard/mouse interface to the widgets data.
These widget classes also include conversions of the Tcl code for event bindings, keyboard focus traversal, menu bars, and menu keyboard traversal. All the Tcl functions have been converted, but the names have changed (systematically) and they have been split up between the various classes in what I hope is an appropriate manner. Name changes are normally: dropping initial tk_ as the Tk-ness is implicit in the
Tk:: prefix, and similarly dropping say Menu from the name if it has been moved the Tk::Menu class. Thus 'proc tkMenuNextEntry' becomes 'sub NextEntry' in Tk::Menu package.
This does for Tk4.0's "images" what
Tk::Widget does for widgets. Images are new to Tk4.0 and the class structure is not mature either.
There are three sub-classes
It is expected that
Tk::Image hierachy will evolve during the "beta" phase of Tk to allow dynamic or aud-loaded image types or photo formats.
Tk::Dialog are examples of composite widgets classes built from the basic
Composite widgets are implemented via multiple inhertance. There are two base classes
A Composite widget is typically defined as derived from
Tk::ScrolledListbox) if it is a
Tk::Frame with sub-widgets, or
Tk::Dialog) if they is a
Tk::Toplevel with subwidgets.
I expect the style and number of composite and derived classes to evolve when Tk reaches a larger number of people during the "beta" phase.