Perl/Tk

[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.