download original
  
- Nicht-Orthogonalitaet (z.B. "Scrolled"-Pseudowidget, aber auch
  Scrollproperties in etlichen Widgets, z.B. Canvas)
- Kompliziertes "configure"-Protokoll
- ($cnv ist ein Canvas)
  DB<17> x $cnv->cget(-scrollregion)
0  0
1  0
2  4375
3  3540
  DB<18> x $cnv->cget(-scrollregion)
  empty array
  ?
- z.T. chaotisch organisierte Manpages (Tk::options, Tk::bind
  usw.). Wo sind die Events dokumentiert, die ein bestimmtes Widget
  aussenden kann? Tk::bind dokumentiert offenbar die
  Tk::Widget-Events...
- Scrollables haben kein Event, das anzeigt, dass gerade gescrollt
  wurde
- keine vernünftige Möglichkeit, eigene Events analog zu den
  vordefinierten (mit "bind" bindbaren) zu definieren
- pro Event nur ein Binding definierbar???
    $schedCanvas->CanvasBind('<Control-5>', sub {
                                print "bind1";
                             });
    $schedCanvas->CanvasBind('<Control-5>', sub {
                                print "bind2";
                             });
  => bind2 überschreibt bind1, nur bind2 wird aufgerufen!!
- manche Events werden überhaupt nicht über "bind"-Listen verbunden,
  sondern über einzelne Variablen (d.h. nur ein Binding pro
  Event). Beispiel: Tk::Scrollbar/-command. Ein "Scrollable" verbindet
  intern die "-command"s seiner Scrollbars. Setzt man die "-command"s
  um, gibt es "witzige" Effekte...
- kein "visible"-Flag für Fenster; wenn Fenster geschlossen werden,
  werden sie scheinbar automatisch zerstört -- Zustände der Widgets
  gehen verloren
- "destroy"-Event eines Fensters wird mehrfach aufgerufen, wenn der
  User das Fenster m.H.des Windowmanagers schließt (offenbar einmal pro
  Kind des Fensters?) 
  
   back to tk 
  
  (C) 1998-2017 Olaf Klischat  <olaf.klischat@gmail.com>