Philipp Hasenfratz: Perl/Tk

Beitrag lesen

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

--
RTFM! - Foren steigern das Aufkommen von Redundanz im Internet, danke für das lesen der Manuals.
Selbstbedienung! - Das SelfForum ist ein Gratis-Restaurant mit Selbstbedienung, Menüangebot steht in den </faq/> und dem </archiv/>.