Linux Certif

Toute la documentation sur la certification Linux LPI

Tk::Tcl-perl.3pm

NAME

Tcl-perl - very old suspect documentation on porting.

DESCRIPTION

This isn't really a .pod yet, nor is it Tcl vs perl it is a copy of John's comparison of Malcolm's original perl/Tk port with the current one. It is also out-of-date in places.

   From: john@WPI.EDU (John Stoffel )
 
   Here are some thoughts on the new Tk extension and how I think the
   organization of the commands looks.  Mostly, I'm happy with it, it
   makes some things more organized and more consistent with tcl/tk, but
   since the overlying language is so different, I don't think we need to
   follow exactly the tcl/tk model for how to call the language.
 
   The basic structure of the Tk program is:
 
       require Tk;
 
       $top = MainWindow->new();
 
       #
       # create widgets
       #
 
       Tk::MainLoop;
 
       sub method1 {
       }
 
       sub methodN {
       }
 
   This is pretty much the same as tkperl5a5, with some cosmetic naming
   changes, and some more useful command name and usage changes.  A quick
   comparison in no particular order follows:
 
   tkperl5a5                             Tk
   -------------------------------       -----------------------------------
   $top=tkinit(name,display,sync);       $top=MainWindow->new();
 
   tkpack $w, ... ;              $w->pack(...)
 
   $w = Class::new($top, ...);   $w = $top->Class(...);
 
   tkmainloop;                   Tk::MainLoop;
 
   tkbind($w,"<key>",sub);               $w->bind("<key>",sub);
 
   tkdelete($w, ...);            $w->delete(...);
 
   $w->scanmark(...);            $w->scan("mark", ...);
 
   $w->scandragto(...);          $w->scan("dragto", ...);
 
   $w->tkselect();                       $w->Select();
 
   $w->selectadjust(...);                $w->selection("adjust", ...);
 
   $w->selectto(...);            $w->selection("to", ...);
 
   $w->selectfrom(...);          $w->selection("from", ...);
 
   $w->tkindex(...);             $w->index(...);
 
   tclcmd("xxx",...);              &Tk::xxx(...)    # all Tk commands, but no Tcl at all
 
   tclcmd("winfo", xxx, $w, ...);  $w->xxx(...);
 
                                 $w->mark(...);
 
                                 $w->tag(...);
 
   $w->grabstatus();             $w->grab("status");
 
   $w->grabrelease(...);         $w->grab("release", ...);
 
   focus($w);                    $w->focus;
 
   update();                     Tk->update();
 
   idletasks();                  Tk->update("idletasks");
 
   wm("cmd",$w, ...);            $w->cmd(...);
 
   destroy($w);                  $w->destroy();
 
                                 Tk::option(...);
                                   $w->OptionGet(name,Class)
 
                                 $w->place(...)
 
                                 Tk::property(...);
 
   $w = Entry::new($parent,...)
 
   is now
 
   $w = $parent->Entry(...)
 
   As this allows new to be inherited from a Window class.
 
     -method=>x,-slave=>y
 
    is now
 
     -command => [x,y]
 
   1st element of list is treated as "method" if y is an object reference.
   (You can have -command => [a,b,c,d,e] too; b..e get passed as args).
 
   Object references are now hashes rather than scalars and there
   is only ever one such per window.  The Tcl_CmdInfo and PathName
   are entries in the hash.
 
   (This allows derived classes to
   re-bless the hash and keep their on stuff in it too.)
 
   Tk's "Tcl_Interp" is in fact a ref to "." window.
   You can find all the Tk windows descended from it as their object
   references get added (by PathName) into this hash.
   $w->MainWindow returns this hash from any window.
 
   I think that it should extend to multiple tkinits / Tk->news
   with different Display's - if Tk code does.
 
   Finally "bind" passes window as "extra" (or only)
   argument. Thus
 
   Tk::Button->bind(<Any-Enter>,"Enter");
 
   Binds Enter events to Tk::Button::Enter by default
   but gets called as $w->Enter so derived class of Button can just
   define its own Enter method. &EvWref and associated globals and race
   conditions are no longer needed.
 
   One thing to beware of : commands bound to events with $widget->bind
   follow same pattern, but get passed extra args :
 
   $widget->bind(<Any-1>,[sub {print shift}, $one, $two ]);
 
   When sub gets called it has :
 
      $widget $one $two
 
   passed.
 
   1st extra arg is reference to the per-widget hash that serves as the
   perl object for the widget.
 
   Every time an XEvent a reference to a special class is placed
   in the widget hash. It can be retrieved by $w->XEvent method.
 
   The methods of the XEvent class are the
   Tcl/Tk % special characters.
 
   Thus:
 
   $widget->bind(<Any-KeyPress>,
                 sub {
                  my $w = shift;
                  my $e = $w->XEvent;
                  print $w->PathName," ",$e->A," pressed ,$e->xy,"\n");
                 });
 
   XEvent->xy is a special case which returns "@" . $e->x . "," . $e->y
   which is common in Text package.
 
   Because of passing a blessed widget hash to "bound" subs they can be
   bound to (possibly inherited) methods of the widget's class:
 
   Class->bind(<Any-Down>,Down);
 
   sub Class::Down
   {
    my $w = shift;
    # handle down arrow
   }
 
   Also:
 
   -command and friends can take a list the 1st element can be a ref to
   as sub or a method name. Remaining elements are passed as args to the
   sub at "invoke" time. Thus :
 
   $b= $w->Button(blah blah, '-command' => [sub{print shift} , $fred ]);
 
   Should do the trick, provided $fred is defined at time of button creation.
 
   Thus 1st element of list is equivalent to Malcolm's -method and second
   would be his -slave.  Any further elements are a bonus and avoid
   having to pass ref to an array/hash as a slave.