.\" -*- mode: troff; coding: utf-8 -*-
.\" Automatically generated by Pod::Man 5.01 (Pod::Simple 3.43)
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" \*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>.
.ie n \{\
.    ds C` ""
.    ds C' ""
'br\}
.el\{\
.    ds C`
.    ds C'
'br\}
.\"
.\" Escape single quotes in literal strings from groff's Unicode transform.
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.\"
.\" If the F register is >0, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
.\" entries marked with X<> in POD.  Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.\"
.\" Avoid warning from groff about undefined register 'F'.
.de IX
..
.nr rF 0
.if \n(.g .if rF .nr rF 1
.if (\n(rF:(\n(.g==0)) \{\
.    if \nF \{\
.        de IX
.        tm Index:\\$1\t\\n%\t"\\$2"
..
.        if !\nF==2 \{\
.            nr % 0
.            nr F 2
.        \}
.    \}
.\}
.rr rF
.\" ========================================================================
.\"
.IX Title "composite 3pm"
.TH composite 3pm 2024-03-07 "perl v5.38.2" "User Contributed Perl Documentation"
.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.if n .ad l
.nh
.SH NAME
Tk::composite \- Defining a new composite widget class
.SH SYNOPSIS
.IX Header "SYNOPSIS"
.Vb 1
\&    package Tk::MyNewWidget;
\&
\&    use Tk::widgets qw/ list of Tk widgets /;
\&    use base qw/ Tk::Frame /;    # or Tk::Toplevel
\&
\&    Construct Tk::Widget \*(AqMyNewWidget\*(Aq;
\&
\&    sub ClassInit {
\&        my( $class, $mw ) = @_;
\&        #... e.g., class bindings here ...
\&        $class\->SUPER::ClassInit( $mw );
\&    }
\&
\&    sub Populate {
\&        my( $self, $args ) = @_;
\&
\&        my $flag = delete $args\->{\-flag};
\&        if( defined $flag ) {
\&            # handle \-flag => xxx which can only be done at create
\&            # time the delete above ensures that new() does not try
\&            # and do  $self\->configure( \-flag => xxx );
\&        }
\&
\&        $self\->SUPER::Populate( $args );
\&
\&        $self = $self\->Component( ... );
\&
\&        $self\->Delegates( ... );
\&
\&        $self\->ConfigSpecs(
\&            \*(Aq\-cursor\*(Aq    => [ SELF, \*(Aqcursor\*(Aq, \*(AqCursor\*(Aq,   undef ],
\&            \*(Aq\-something\*(Aq => [ METHOD, dbName,  dbClass, default ],
\&            \*(Aq\-text\*(Aq      => [ $label, dbName,  dbClass, default ],
\&            \*(Aq\-heading\*(Aq   => [ {\-text => $head},
\&                                heading, Heading,  \*(AqMy Heading\*(Aq ],
\&       ); 
\&   }
\&
\&   sub something {
\&       my( $self, $value) = @_;
\&       if ( @_ > 1 ) {
\&          # set it
\&       }
\&       return # current value
\&   }
\&
\&   1;
\&
\&   _\|_END_\|_
\&
\&
\&   =head1 NAME
\&
\&   Tk::Whatever \- a whatever widget
\&
\&   =head1 SYNOPSIS
\&
\&     use Tk::Whatever;
\&
\&     $widget = $parent\->Whatever(...);
\&
\&   =head1 DESCRIPTION
\&
\&   ...
.Ve
.SH DESCRIPTION
.IX Header "DESCRIPTION"
The intention behind a composite is to create a higher-level widget,
sometimes called a "super-widget" or "mega-widget".  Most often,
a composite will be
built upon other widgets by \fBusing\fR them, as opposed to specializing on them.
For example, the supplied composite widget \fBLabEntry\fR is \fImade of\fR an
\&\fBEntry\fR and a \fBLabel\fR; it is neither a \fIkind-of\fR \fBLabel\fR
nor is it a \fIkind-of\fR \fBEntry\fR.
.PP
Most of the work of a composite widget consistd in creating subwidgets,
arranging to dispatch configure options to the proper subwidgets and manage
composite-specific configure options.
.SH "GLORY DETAILS"
.IX Header "GLORY DETAILS"
Depending on your Perl/Tk knowledge this section may be enlighting
or confusing.
.SS "Composite Widget"
.IX Subsection "Composite Widget"
Since Perl/Tk is heavilly using an object-oriented approach, it is no
suprise that creating a composite goes through a \fBnew()\fR method.
However, the composite does not normally define a \fBnew()\fR method
itself: it is usually sufficient to simply inherit it from
\&\fBTk::Widget\fR.
.PP
This is what happens when the composite uses
.PP
.Vb 1
\&    use base qw/ Tk::Frame /;  # or Tk::Toplevel
.Ve
.PP
to specify its inheritance chain.  To complete the initialisation of the
widget, it must call the \fBConstruct\fR method from class \fBWidget\fR.  That
method accepts the name of the new class to create, i.e. the package name
of your composite widget:
.PP
.Vb 1
\&    Construct Tk::Widget \*(AqMyNewWidget\*(Aq;
.Ve
.PP
Here, \fBMyNewWidget\fR is the package name (aka the widget's \fBclass\fR).  This
will define a constructor method for \fBMyNewWidget\fR, normally named after the
widget's class.  Instanciating that composite in client code would
the look like:
.PP
.Vb 1
\&    $mw = MainWindow\->new;       # creates a top\-level MainWindow
\&
\&    $self = $mw\->MyNewWidget();  # creates an instance of the
\&                                 # composite widget MyNewWidget
.Ve
.PP
Whenever a composite is instanciated in client code,
\&\f(CWTk::Widget::new()\fR will be invoked via the widget's class
constructor.  That \fBnew\fR method will call
.PP
.Vb 1
\&    $self\->Populate(\e%args);
.Ve
.PP
where \fR\f(CI%args\fR\fI\fR is the arguments passed to the widget's constructor.  Note
that \fBPopulate\fR receives a \fBreference\fR to the hash array
containing all arguments.
.PP
\&\fBPopulate\fR is typically defined in the composite class (package),
which creates the characteristic subwidgets of the class.
.SS "Creating Subwidgets"
.IX Subsection "Creating Subwidgets"
Subwidget creation happens usually in \fBPopulate()\fR.
The composite usually calls the
subwidget's constructor method either directly, for "private" subwidgets,
or indirectly through the \fBComponent\fR method for subwidgets that should
be advertised to clients.
.PP
\&\fBPopulate\fR may call \fBDelegates\fR to direct calls to methods
of chosen subwidgets. For simple composites, typically most if not all
methods are directed
to a single subwidget \- e.g. \fBScrListbox\fR directs all methods to the core
\&\fBListbox\fR so that \fR\f(CI$composite\fR\fI\fR\->\fBget\fR(...) calls
\&\fI\fR\f(CI$listbox\fR\fI\fR\->\fBget\fR(...).
.SS "Defining mega-widget options"
.IX Subsection "Defining mega-widget options"
\&\fBPopulate\fR should also call \fBConfigSpecs()\fR to specify the
way that configure-like options should be handled in the composite.
Once \fBPopulate\fR returns, method \fBTk::Frame::ConfigDefault\fR
walks through the \fBConfigSpecs\fR entries and populates
%$args hash with defaults for options from X resources (\fI.Xdefaults\fR, etc).
.PP
When  \fBPopulate\fR returns to \fBTk::Widget::new()\fR,
a call to \fR\f(CB$self\fR\fB\fR\->\fIconfigure\fR(%$args) is made which sets *all*
the options.
.SH "SEE ALSO"
.IX Header "SEE ALSO"
Tk::ConfigSpecs
Tk::mega
Tk::Derived