Perl/Tk

[Philipp Hasenfratz]

Halihallo alle

Meine Erfahrungen mit Perl/Tk sind zwar etwas vorhanden, halten sich jedoch in
beträchtlichen Grenzen...

Als ich in der Dokumentation und im Internet gesucht habe, habe ich nur allgemeine
Beispiele und Codes gefunden, die auf demselben MainWindow und Design operieren. Ich
suche nach einer Lösung, wie ich in einem MainWindow mehrere Ansichten parallel
verwalten kann. Beispiel: Ich habe z.B. eine Adresskartei. Im MainWindow sollen nun
die Kontakte in einer Liste aufgezeigt werden, aber in _demselben_ MainWindow sollen
die Einträge dann auch bearbeitet werden können.

Ich dachte mir, einfach einen MainFrame auf das ganze MainWindow zu setzen, indem jedoch
mehrere, sich vollständig überlagernde Frames eingebettet sind. Ein Frame für
"Adresse bearbeiten", ein Frame für "Adressliste anzeigen", ... Je nach Ansichtsmodus
soll dann der eine oder andere Frame sichtbar werden. Nur weiss ich a) nicht, wie ich
Frames mal sichtbar mal unsichtbar darstellen kann und b) ob dies in Tk so
üblich/möglich ist.
Wie würdet Ihr sowas umsetzen?

Zweite Frage zur Umsetzung:
Bei z.B. Delphi ist jedes Formular eine eigene Klasse. Selbst das Design ist
"objektorientiert". In Perl/Tk ist es meistens so (das entnehme ich den Online
Beispielen), dass ein Script die Frames, Menus, ..., einfach Widgets definiert, einige
Callbacks definiert, die im selben Script definiert sind und dann in den MainLoop geht.
Keine Module... Ich wünschte mir jedoch eine OO-Umsetzung, so habe ich mir folgendes
überlegt:

Jede "Funktionalität" so z.B. Adresse bearbeiten, Adresse anzeigen, ... wird in einer
Klasse abgebildet. Nehmen wir als Beispiel "Adresse bearbeiten":

Diese Klasse enthält eine Methode "design", der das MainWindow-Widget übergeben wird,
es erstellt das ganze "Design" zu "Adresse bearbeiten" und speichert die Widgets im
Modul-Scope (globale Variablen der Klasse), sodass alle Methoden der Klasse (Callbacks)
auf diese Widgets zugreifen und verändern können. Die Backticks sind dann in der Form
sub { $self->callback_name_edited() }; übergeben. Somit haben wir Design und Code einer
Funktionalität vollständig in einem Modul.

Meine Frage: Wie könntet Ihr euch eine OOP-Umsetzung eines Tk-GUI-Programmes vorstellen?
Wie habt ihr es evtl. schon gelöst? - Was haltet Ihr von meinem Vorschlag?

Viele Grüsse

Philipp

[Christoph Schnauß]

hallo Philipp,

Meine Erfahrungen mit Perl/Tk sind zwar etwas vorhanden, halten sich jedoch in beträchtlichen Grenzen...

Mit dem Tk-Modul in PERL habe ich mich lange nicht mehr beschäftigt, aber dafür mit TCL/Tk  -  und aus dieser Sprache kommt ja das, was das PERL-Modul umzusetzen veraucht.

Ich dachte mir, einfach einen MainFrame auf das ganze MainWindow zu setzen, indem jedoch mehrere, sich vollständig überlagernde Frames eingebettet sind.

Das sollte prinzipiell möglich sein

Nur weiss ich nicht, wie ich Frames mal sichtbar mal unsichtbar darstellen kann

Das erledigt der "Packer" für dich, bzw. der Geometriemanager. "expand" und "fill" sind Optionen, die deinem Frame oder Label eine Größe geben. Und nichts hindert dich, in ein "MainWindow" mehrere Widgets einzubauen, siehe perldoc Tk::MainWindow.

Meine Frage: Wie könntet Ihr euch eine OOP-Umsetzung eines Tk-GUI-Programmes vorstellen?

Du kannst dir einzelne Widgets als "Module" definieren. TCL/Tk ist von seinem Wesen her ereignisorientiert, das Konzept für OOP heißt "incr TCL" bzw. "incr Tk"  -  schau mal, ob du dazu was findest.

Du solltest dir vielleicht zum Vergleich mal TCL/Tk holen, das bekommst du entweder von http://www.activestate.com/Products/Download/Download.plex?id=ActiveTcloder von http://dev.scriptics.com/software/tcltk/downloadnow84.tml. Bei den dort mitgelieferten Beispielen gibt es bei den "iwidgets" (für "incr widgets", also OOP) mit "tabnotebook" eins, das deinen Wünschen sehr nahe kommen dürfte und als Vergleich für eine Umsetzung in PERL/Tk sicher ein paar brauchbare Hinweise enthält.

Wie habt ihr es evtl. schon gelöst? - Was haltet Ihr von meinem Vorschlag?

Ich habe mich seit mehr als einem Jahr nicht mehr mit PERL/Tk beschäftigt, weil ich zwar auf dem Server umfangreiche und ansprechende GUI-Lösungen zusammenbauen konnte, die aber nicht "reansportierbar" waren. Das war zumindest bei Perl 5.6 so  -  und was nutzt es, wenn mir der Besuch eines "users" auf dem Server die schönsten Widgets aufruft, er sie aber nicht zu sehen bekommt? Wenn du mir sagen kannst, wie ein "user" übers Internet das gewünschte GUI auch auf seinen Monitor bekommen kann, ohne selbst PERL installiert haben zu müssen (dann funktioniert das ganz gut), klemme ich mich nochmal dahinter  -  ich halte nämlich Tk für eine ausgesprochen feine Sache.

Grüße aus Berlin

Christoph S.

[Philipp Hasenfratz]

Halihallo Christoph

Meine Erfahrungen mit Perl/Tk sind zwar etwas vorhanden, halten sich jedoch in beträchtlichen Grenzen...
Mit dem Tk-Modul in PERL habe ich mich lange nicht mehr beschäftigt, aber dafür mit TCL/Tk  -  und aus dieser Sprache kommt ja das, was das PERL-Modul umzusetzen veraucht.

Ist eh alles das selbe :-)
Ob nun Perl oder TCL spielt ja eine nebensächliche Rolle :-)

Nur weiss ich nicht, wie ich Frames mal sichtbar mal unsichtbar darstellen kann
Das erledigt der "Packer" für dich, bzw. der Geometriemanager. "expand" und "fill" sind Optionen, die deinem Frame oder Label eine Größe geben. Und nichts hindert dich, in ein "MainWindow" mehrere Widgets einzubauen, siehe perldoc Tk::MainWindow.

Letzteres ist klar. Bei Ersterem bin ich mir dessen noch nicht sicher, wie ich es
umsetzen kann. Die Perl-Doku (TCL wirds das selbe sein, da beide auf (etwa) die selbe
Library zurückgreifen) besagt:

--------------------------------------------------------------------------------------
-expand => boolean
   Specifies whether the slave should be expanded to consume extra space in their
   master. Boolean may have any proper boolean value, such as 1 or no. Defaults to 0.

-fill => style
   If a slave's parcel is larger than its requested dimensions, this option may be used
   to stretch the slave. Style must have one of the following values:
 none
  Give the slave its requested dimensions plus any internal padding requested with -
  ipadx or -ipady. This is the default.

x
  Stretch the slave horizontally to fill the entire width of its parcel (except leave
  external padding as specified by -padx).

y
  Stretch the slave vertically to fill the entire height of its parcel (except leave
  external padding as specified by -pady).

both
  Stretch the slave both horizontally and vertically.
--------------------------------------------------------------------------------------

Falls also "-expand 0 -fill none" gesetzt wird, hat das Widget immer noch eine Grösse,
zwar die Minimale, aber dennoch: sichtbar ist es. Zumindest im Geometrymanager pack
habe ich bisher keine Möglichkeit gefunden ein Widget temporär als "invisible" also
unsichtbar zu kennzeichnen :-(

Meine Frage: Wie könntet Ihr euch eine OOP-Umsetzung eines Tk-GUI-Programmes vorstellen?
Du kannst dir einzelne Widgets als "Module" definieren. TCL/Tk ist von seinem Wesen her ereignisorientiert, das Konzept für OOP heißt "incr TCL" bzw. "incr Tk"  -  schau mal, ob du dazu was findest.

Hm. Im Perl ist Tk auch Ereignisorientiert und wird's auch immer bleiben. Ich weiss noch
nicht genau, was ich dem [incr Tk] abgewinnen kann, aber es seint nicht das zu sein,
was ich mir vorstelle, obwohl man kann von den Widgets erben und sie erweitern, das ist
schon mal ein Schritt in die richtige Richtung. Mir geht es darum, dass Tk gar nicht
separat steht, sondern voll in den Programmfluss einläuft... Ich habe schon mal etwas
getestet, scheint ganz gut zu funktionieren. Design und Funktionalität in einem Modul
zu vereinen.

Du solltest dir vielleicht zum Vergleich mal TCL/Tk holen, das bekommst du entweder von http://www.activestate.com/Products/Download/Download.plex?id=ActiveTcloder von http://dev.scriptics.com/software/tcltk/downloadnow84.tml. Bei den dort mitgelieferten Beispielen gibt es bei den "iwidgets" (für "incr widgets", also OOP) mit "tabnotebook" eins, das deinen Wünschen sehr nahe kommen dürfte und als Vergleich für eine Umsetzung in PERL/Tk sicher ein paar brauchbare Hinweise enthält.

Hm. Vielen Dank für den Tipp.

Wie habt ihr es evtl. schon gelöst? - Was haltet Ihr von meinem Vorschlag?
Ich habe mich seit mehr als einem Jahr nicht mehr mit PERL/Tk beschäftigt, weil ich zwar auf dem Server umfangreiche und ansprechende GUI-Lösungen zusammenbauen konnte, die aber nicht "reansportierbar" waren. Das war zumindest bei Perl 5.6 so  -  und was nutzt es, wenn mir der Besuch eines "users" auf dem Server die schönsten Widgets aufruft, er sie aber nicht zu sehen bekommt? Wenn du mir sagen kannst, wie ein "user" übers Internet das gewünschte GUI auch auf seinen Monitor bekommen kann, ohne selbst PERL installiert haben zu müssen (dann funktioniert das ganz gut), klemme ich mich nochmal dahinter  -  ich halte nämlich Tk für eine ausgesprochen feine Sache.

Uha, was hast du denn da vor :-)
Nun, HTTP eignet sich dafür eigentlich schlecht, denn du brauchst eine bidirektionale
Verbindung mit dem, meinetwegen Perl/Tk-Server; das ist über HTTP wenn, dann nur
ineffizient lösbar. Auch wenn du es schaffen würdest, Events über die Verbindung zu
senden, so musst du noch eine Möglichkeit finden, das aktuelle Fenster über die
Verbindung zurückzusenden, sodass der Client (Browser) es darstellen kann (vorzugsweise
Graphik). Dafür kenne ich leider keine Technik/Programm (ich würde es mir auch wünschen
:-)). Das was dem am nächsten kommt sind die ASP, Application Service Providers. Da hat
man z.B. Outlook Express auf dem Server laufen und mehrere Clients greifen
über diesen Provider darauf zu. Der ASP liest dann den Fensterinhalt aus und liefert sie
dem Client als HTML-File (wahrscheinlich bestehend aus diversen Bildern) zurück.

Ob und wo es etwas derartiges für Perl/Tk gibt, weiss ich leider nicht.

Viele Grüsse und Danke

Philipp

[Christoph Schnauß]

guten Abend,

Mit dem Tk-Modul in PERL habe ich mich lange nicht mehr beschäftigt, aber dafür mit TCL/Tk
Ist eh alles das selbe :-)

Jaein. PERL bleibt PERL und verlangt zum Beispiel eine andere "shebang", aber das ist tatsächlich nur ein minimaler Unterschied.

Ob nun Perl oder TCL spielt ja eine nebensächliche Rolle :-)

Ja, _nebensächlich_, und grade deshalb kanns den einen oder anderen Stolperstein geben, wenn man versucht, funktionierenden TCL/Tk-Code nach PERL zu "transformieren".

Das erledigt der "Packer" für dich, bzw. der Geometriemanager. "expand" und "fill" sind Optionen, die deinem Frame oder Label eine Größe geben. Und nichts hindert dich, in ein "MainWindow" mehrere Widgets einzubauen
Letzteres ist klar. Bei Ersterem bin ich mir dessen noch nicht sicher, wie ich es umsetzen kann.

Naja, üben, üben, üben ;-)
Im Übrigens ist "pack" zwar der wahrscheinlich mächtigste und meist als "default" eingesetzte Geometrie-Manager, aber es gibt noch zwei andere  -  grid und place. Die stehen auch in PERL/Tk zur Verfügung, wie ich eben nochmal nachgelesen habe.

Falls also "-expand 0 -fill none" gesetzt wird, hat das Widget immer noch eine Grösse, zwar die Minimale, aber dennoch: sichtbar ist es.

Du hast mich jetzt ein bißchen auf dem falschen Fuß erwischt, ich habe hier im Moment kein TCL/Tk installiert (PERL ist vorhanden) und kann auf meine eigenen TCL-Projekte nicht zugreifen. Daher kann ich im Augenblick nur aussagen, _daß es geht_  -  sorry, ich würds dir gerne mit einem Beispiel untersetzen, kann aber nicht.

Zumindest im Geometrymanager pack habe ich bisher keine Möglichkeit gefunden ein Widget temporär als "invisible" also unsichtbar zu kennzeichnen :-(

Ich bin mir nicht ganz sicher, aber ich glaub, ich hab das mit negativen Größenangaben hingekriegt. Im Prinzip ist der optische Effekt derselbe wie bei sichtbaren/unsichtbaren DIV's in HTML  -  der Vergleich hinkt gewaltig, weil es nicht nur auf den optischen Effekt ankommt, sondern zum Beispiel auch auf die Speicherbelastung.

Hm. Im Perl ist Tk auch Ereignisorientiert und wird's auch immer bleiben.

Wofür ich sogar ganz dankbar bin. Es gibt eine Menge Situationen, in denen ereignisorientierte Programmierung immer noch ihre Berechtigung hat. Das ändert natürlich nix daran, daß OOP mit Recht zum "Standard" geworden ist.

Ich weiss noch nicht genau, was ich dem [incr Tk] abgewinnen kann, aber es seint nicht das zu sein, was ich mir vorstelle, obwohl man kann von den Widgets erben und sie erweitern, das ist schon mal ein Schritt in die richtige Richtung.

Naja, war ja auch nur nen Hinweis.

Ich habe schon mal etwas getestet, scheint ganz gut zu funktionieren. Design und Funktionalität in einem Modul zu vereinen.

Na bitte ;-) Allerdings muß man manchmal, wenn man 20 oder mehr Stunden am Rechner gesessen hat, eine kleine Pause machen und den Kopf ausschütteln und vielleicht hier 'ne Frage stellen  -  auch wenns nicht _viel_ bringt, bringt das doch meistens die Überwindung der eigenen "Betriebsblindheit".

Du solltest dir vielleicht zum Vergleich mal TCL/Tk holen [...]
Hm. Vielen Dank für den Tipp.

Mir haben die Beispiele, die es da gibt, schon sehr viel weitergeholfen.

Wenn du mir sagen kannst, wie ein "user" übers Internet das gewünschte GUI auch auf seinen Monitor bekommen kann
Uha, was hast du denn da vor :-)

Och, ich träume halt nen bißchen. Ich bin vor mehreren Jahren auf TCL/Tk aufmerksam geworden, weil der einzige _sinnvolle_ Dateimanager in SuSE 4.x in TCL/Tk geschrieben war (siehe http://tkdesk.sourceforge.net). Ich habe halt ein bissel damit herumgespielt und gebastelt  -  der Effekt ist bisher, daß ich zur Zeit sowohl unter Windows wie unter LINUX/FreeBSD mit jeweils identischem Software-Code meinen eigenen FTP-Client benutze. Letzten Endes würde ich gerne sowas haben, daß beim Anklicken eines Links ein (PERL-)Tk-GUI auf dem "user"-Monitor aufgeht ...

Nun, HTTP eignet sich dafür eigentlich schlecht, denn du brauchst eine bidirektionale Verbindung

menno, warum mußt du nur so fürchterlich Recht haben :-(

Das was dem am nächsten kommt sind die ASP, Application Service Providers.

Zumindest ansatzweise scheint das auch mit JSP (Tomcat als Server) zu funktionieren, da versuche ich mich grade reinzuarbeiten. Für HTML&Co. liegt die Alternative offensichtlich in SVG/XML.

Aber um auf das Thema zurückzukommen: Wir haben bedauerlicherweise ziemlich wenig Nachfragen zu PERL/Tk hier im Forum. Aber ich weiß, daß Antje Hofmann (sollte dir ein Begriff sein) sehr viel von TCL/Tk versteht und dir sicher noch ein paar Tipps geben kann, die auch mit PERL/Tk umsetzbar sein dürften. Für TCL/Tk selbst (also nicht das Perl-Modul) gibt es übrigens auch mit comp.lang.tcl eine relativ gut besuchte newsgroup (englsichsprachig). Gelegentlich wird dort in Ermangelung eines Besseren auch PERL/Tk angesprochen.

Ich verstehe noch nicht ganz, _wo_ du dein PERL/Tk-GUI einsetzen willst. Übers Internet gewiß nicht, aber es soll doch gewiß nicht nur Selbstbefriedigung sein, sondern auch anderen Leuten zur Verfügung gestellt werden. Soll das als Konsolenapplikation laufen oder über ein "verteiltes" System?

Grüße aus Berlin

Christoph S.

[Philipp Hasenfratz]

Halihallo Christoph

Ob nun Perl oder TCL spielt ja eine nebensächliche Rolle :-)
Ja, _nebensächlich_, und grade deshalb kanns den einen oder anderen Stolperstein geben, wenn man versucht, funktionierenden TCL/Tk-Code nach PERL zu "transformieren".

Ja, da hast du recht. Ich wollte nur sagen, dass alle 4th GL (Script-Sprachen) Languages
etwa die selben Funktionen und Möglichkeiten bieten. Man braucht, etwas salop
ausgedrückt, einfach eine andere Syntax zu lernen. Das aber Stolpersteine vorhanden
sind, kann ich nicht dementieren :-)

Falls also "-expand 0 -fill none" gesetzt wird, hat das Widget immer noch eine Grösse, zwar die Minimale, aber dennoch: sichtbar ist es.
Du hast mich jetzt ein bißchen auf dem falschen Fuß erwischt, ich habe hier im Moment kein TCL/Tk installiert (PERL ist vorhanden) und kann auf meine eigenen TCL-Projekte nicht zugreifen. Daher kann ich im Augenblick nur aussagen, _daß es geht_  -  sorry, ich würds dir gerne mit einem Beispiel untersetzen, kann aber nicht.

Falls Du noch die Gelegenheit dazu bekommen wirst, wäre ich Dir natürlich sehr dankbar.
Aber irgendwie und irgendwann werd ich's auch hinkriegen :-)

Zumindest im Geometrymanager pack habe ich bisher keine Möglichkeit gefunden ein Widget temporär als "invisible" also unsichtbar zu kennzeichnen :-(
Ich bin mir nicht ganz sicher, aber ich glaub, ich hab das mit negativen Größenangaben hingekriegt.

Grössenangaben bei pack? - Du verwirrst mich schon wieder :-)
Bei Pack gibts IMHO keine absoluten Grössenangaben. Ich hab mich mal umgesehen,
vielleicht kann mir der place-Geometrymanager helfen. Dort gibt's width and height. Der
kommt wohl dem position: absolute|relative bei DIV's am nächsten :-) gut, muss ja nicht
div's nachahmen. Das geht bestimmt auch andersweitig.

Hm. Im Perl ist Tk auch Ereignisorientiert und wird's auch immer bleiben.
Wofür ich sogar ganz dankbar bin. Es gibt eine Menge Situationen, in denen ereignisorientierte Programmierung immer noch ihre Berechtigung hat. Das ändert natürlich nix daran, daß OOP mit Recht zum "Standard" geworden ist.

Die beiden beissen sich ja nicht. Es gibt auch ereignisorientierte Systeme, die komplett
in OOP umgesetzt sind. Bei Tk werden die Events eben über Callbacks ausgeführt, in einer
OOP-Umsetzung über Methodenaufrufe. Ereignisorientiert/OOP sehe ich nicht umbedingt als
konkurrierende Konzepte.

Ich habe schon mal etwas getestet, scheint ganz gut zu funktionieren. Design und Funktionalität in einem Modul zu vereinen.
Na bitte ;-) Allerdings muß man manchmal, wenn man 20 oder mehr Stunden am Rechner gesessen hat, eine kleine Pause machen und den Kopf ausschütteln und vielleicht hier 'ne Frage stellen  -  auch wenns nicht _viel_ bringt, bringt das doch meistens die Überwindung der eigenen "Betriebsblindheit".

Full ACK ;)

Du solltest dir vielleicht zum Vergleich mal TCL/Tk holen [...]
Hm. Vielen Dank für den Tipp.
Mir haben die Beispiele, die es da gibt, schon sehr viel weitergeholfen.

Ich werde sie mir auch noch ansehen, runter isses schon mal :-)

Wenn du mir sagen kannst, wie ein "user" übers Internet das gewünschte GUI auch auf seinen Monitor bekommen kann
Uha, was hast du denn da vor :-)
Och, ich träume halt nen bißchen. Ich bin vor mehreren Jahren auf TCL/Tk aufmerksam geworden, weil der einzige _sinnvolle_ Dateimanager in SuSE 4.x in TCL/Tk geschrieben war (siehe http://tkdesk.sourceforge.net). Ich habe halt ein bissel damit herumgespielt und gebastelt  -  der Effekt ist bisher, daß ich zur Zeit sowohl unter Windows wie unter LINUX/FreeBSD mit jeweils identischem Software-Code meinen eigenen FTP-Client benutze. Letzten Endes würde ich gerne sowas haben, daß beim Anklicken eines Links ein (PERL-)Tk-GUI auf dem "user"-Monitor aufgeht ...

Das wäre wirklich genial! - Meiner Meinung nach gibt es zwei Möglichkeiten:
Entweder man geht von minimalem Client-System aus und verwendet vorhandene Techniken
=> Browser, SVG oder Bitmap

Oder man geht von einem angepassten Client-System aus und verwendet dort einen
entsprechenden Client. Das könnte z.B. ein spezielles Browser-Plugin sein, oder sowas
wie pcAnywhere.

Aber um auf das Thema zurückzukommen: Wir haben bedauerlicherweise ziemlich wenig Nachfragen zu PERL/Tk hier im Forum. Aber ich weiß, daß Antje Hofmann (sollte dir ein Begriff sein)

Leider wahr, Perl/Tk wird höchst selten besprochen... und ja, Antje ist mir ein
Begriff ;)

sehr viel von TCL/Tk versteht und dir sicher noch ein paar Tipps geben kann, die auch mit PERL/Tk umsetzbar sein dürften.

Vielleicht schaut Sie ja noch rein? - Hallihallo Antje, do you copy? :-)

Für TCL/Tk selbst (also nicht das Perl-Modul) gibt es übrigens auch mit comp.lang.tcl eine relativ gut besuchte newsgroup (englsichsprachig). Gelegentlich wird dort in Ermangelung eines Besseren auch PERL/Tk angesprochen.

Ich mag SelfForum viel zu gut, da frage ich erst hier nach. Wenn ich keine Antwort finde
kann ich's aber wirklich mal wo anders versuchen, wo diese "Technik" etwas mehr im
Mittelpunkt steht. Hast recht.

Ich verstehe noch nicht ganz, _wo_ du dein PERL/Tk-GUI einsetzen willst. Übers Internet gewiß nicht, aber es soll doch gewiß nicht nur Selbstbefriedigung sein, sondern auch anderen Leuten zur Verfügung gestellt werden. Soll das als Konsolenapplikation laufen oder über ein "verteiltes" System?

Selbstbefriedigung, Du bist gut :-)
Nun, es dient nicht dem Allgemeinwohl. Es ist eine firmeninterne Angelegenheit um gewisse
Arbeitsprozesse zu verbessern (äm, ist das jetzt die Definition jeder Software? *g*).
Closed Source, leider :-(

Viele Grüsse

Philipp

[Philipp Hasenfratz]

Halihallo

Ich dachte mir, einfach einen MainFrame auf das ganze MainWindow zu setzen, indem jedoch
mehrere, sich vollständig überlagernde Frames eingebettet sind. Ein Frame für
"Adresse bearbeiten", ein Frame für "Adressliste anzeigen", ... Je nach Ansichtsmodus
soll dann der eine oder andere Frame sichtbar werden. Nur weiss ich a) nicht, wie ich
Frames mal sichtbar mal unsichtbar darstellen kann und b) ob dies in Tk so
üblich/möglich ist.
Wie würdet Ihr sowas umsetzen?

Die einfachsten Lösungen sind immer noch die besten. Nur muss man sie finden :-)

Wenn man einen Frame (oder allg. Widgets) verstecken möchte:

$frm->placeForget | $frm->packForget | ...

Wenn man ihn wieder sichtbar machen will:

$frm->place( [opts] ) | $frm->pack( [opts] ) | ...

Manno, im nachhinein ist immer alles so einfach... :-(

Viele Grüsse

Philipp

[Philipp Hasenfratz]

Halihallo

Für's Archiv und aufmerksame Leser noch ein sinnvolles Subject.

Viele Grüsse

Philipp