[quote=lichtkind,17.11.2005, 11:23]nur das das wx von sich aus kann ohne zusatz.[/quote]Das ist eine Frage des Packaging. Ich könnte ja auch einwerfen, dass der Perl-Port von Wx nicht ohne libwx und weiterer externer Bibliotheken funktioniert, während der Perl-Port von Tk keinerlei Abhängigkeiten hat.

Quote

da ich tk nur überflogen habe kann ich nur merken mit was für eine philosophie es entwickelt wurde. das ist eine andere als wx und es würde mich schon überraschen wenn es letztlich nicht so ist wie ich vermute. Das Tk von einer benutzer sich aus entwickelt ist und wx mehr aus der perspektive eines systemprogrammierers.

klar wx brauch ein passing by parameter interface wie tk ohn umständlich konstanten anmelden zu müssen, dafür muss ich nicht jede kleine klasse anmelden. den vorteil das es bei tk mehr perl entwickler gibt wird teilweise ausgeglichen das die meisten entwickler beri wx auf c++ seite sind und mattia mit seinem generischen XS code aktualisierten konstanten listen und einigen helfern damit halbwegs schritt halten kann.

Es hört sich so an, als ob sich Tk zu Wx wie Perl zu C/C++ verhält. Auch die Argumentation der jeweiligen Benutzer ist überraschend ähnlich: ein C/C++-Programmierer hält Perl für eine Programmiersprache, mit der man schnell ein kleines Problemchen in zehn Zeilen lösen kann, mehr aber nicht. Der Perl-Programmierer weiß aber, dass er mit Perl so gut wie alles machen kann, höchstens Kernel- und Treiberprogrammierung lässt man lieber sein. Und während Perl zwischen Effizienz und Komfort für den Programmierer öfter letzteres wählt, ist es bei C/C++ andersrum --- ähnlich wie bei Tk vs. Wx.

das ist nicht ganz richtig weil tk von den gleichen leuten wie Tcl kommt wo man schon öfters mehr an funktionalität weglässt als es dem durchschnittlichen perl benutzer lieb ist. einfachheit ist gut wenn aber die kontrolle über bestimmte prozesse fehlt, dann hilft mir auch keine einfachheit. es hat erstens auch was mit proffessionellen progragrammen zu tun auch mal das draw verhalten und bestimmte events umzubiegen bis man genau das erhält was man haben möchte was in tk soweit ich merkte nicht möglich ist. gibt es in tk auch ein widget um OGL zu rendern?

Ja. Tk::Zinc braucht wohl für maximale Unterstützung OpenGL-Support, und das OpenGL-Modul aus dem CPAN hat in examples auch ein tk_demo.

Und was Tcl angeht: ich glaube, da hast du Unrecht. Tcl hat auch alles (nun, das meiste), was Perl auch hat: Arrays, Hashes, Regular Expressions, eine Schnittstelle zum Einbinden von fremden Code, Packages. OO fehlt (bewusst), aber Tcl ist halt für Erweiterbarkeit geschrieben, und wenn man OO braucht, nimmt man halt incr Tcl. Womit ein Perl-Hacker nicht klarkommt, ist dass Tcl das Gegenteil von DWIM ist.

Und bitte ein konkretes Beispiel zum Event-Verbiegen, ich kann mir darunter nichts vorstellen!

Tk::Zinc ist wirklich ein gutes Modul, auch wenn noch nicht alles von Tk::Canvas umgesetzt wurde...

ich meinte das eigentlich anders, ich wollte wissen wie man in Tk in einen bereich was mit ogl reinrendert. das zinc ogl brauch um sowas zu machen ist bezeichnend denn in wx ist es nicht so, da ist ogl nativ schon eingebunden und es gibt DC = draw context wo man völlige freiheit darüber hat was wie gezeichnet wird und wann es erneuert wird. aber um das im detail zu besprechen würde ich gerne vorher etwas mehr zu tk wissen.

Perls DWIM ist ja dazu da arbeit zu sparen was auch aufgabe einer bibliothek ist. da empfinde ich es etwas als kontaproduktiv zu sagen das es prinzipiell geht. tcl war ja anfangs auch rein stringbasierend entworfen und dann durch perl konkurenzdruck völlig umgearbeitet worden. ähnlich versuchen sie mit den umarbeiten und vielen erweiterungen aus tk etwas zu machen wofür es ursprünglich nicht gedacht war anstatt bei deren stärken zu bleiben. wx ist einfach die bessere basis, ohne tcl interpreter im hintergrund, schneller(wx ist sehr auf geschwindigkeit optimiert programmiert) und auch mit mehr freiheit sachen zu erweitern, nur leider zwingt es einen in perl wie in c++ zu schreiben weil wxperl ein einfacher wrapper um die c++ bibliothek ist.

@lichtkind: warum lernst du nicht einfach mal PerlTk? Dann kannst du vielleicht die Staerken beider Bibliotheken viel hoeher schaetzen und findest auch mehr ueber die jeweiligen Schwaechen heraus, und kannst dann auch viel fundierter sagen, warum wx viel besser ist.

Nebenbei: wenn ich es recht verstanden habe, ist bei Tk kein Tcl-Interpreter im Hintergrund; Tcl kann naemlich hervorragend auf C-Bibliotheken zugreifen, so auch auf Tk; aber Perl kann das ebenso.

Und noch zur Groesse: ich habe in Perl/Tk schon groessere Applikationen geschrieben, meine letzte hatte etwa 16.000 Zeilen Code (ja, ich habe auch schleifen und subroutinen verwendet!), und es ging wunderbar.

@ptk: ich arbeite momentan recht viel mit Tcl (8.3, da sind noch die meisten Perl-Einfluesse aussen vorgeblieben; die meisten kommen erst ab 8.4); ich gebe dir da voellig recht; ich habe da auch meine Probleme.\n\n

<!--EDIT|Strat|1132580510-->

ja nur im moment will und kann mir teilweise die zeit nicht nehmen weil ich pce 0.3.4 ASAP bringen will weil adams pläne davon abhängig sind.

ich habe von den leuten die perl/tk gemacht haben gelesen das da diue ganze zeit ein minimales tcl im hintergrund läuft weil es nicht sauber zu trennen ist. ich vermute auch das ist der grund der probleme mit multithreading in tcl.

noch mal generell ich hab nichts gegen tcl nur ich würde halt lieber sehen wenn man alternativen mit unterschiedlichen stärken hätte und im moment scheinen tk und wx in etwas gleiches ziel zu haben wofür wx die bessere basis ist, aber bis ich dafür die guten argumente habe werde ich wirklich noch etwas tk studieren.

[quote=lichtkind,21.11.2005, 21:22]ich habe von den leuten die perl/tk gemacht haben gelesen das da diue ganze zeit ein minimales tcl im hintergrund läuft weil es nicht sauber zu trennen ist.[/quote]Vielleicht verwechselst du das mit Python und Tkinter. Dort scheint die Kopplung ziemlich lose zu sein (obwohl ich mich nicht so genau auskenne). Bei den Perl-Modulen Tcl::Tk und Tcl ist die Kopplung auch relativ lose. Dort braucht man sowohl libtcl und libtk und der Perl-Glue-Code ruft einen Tcl-Interpreter auf. Tcl::Tk wird allerdings sehr selten verwendet. Bei Perl/Tk wurde aber der gesamte Glue-Code ausgewechselt. Wenn du im Tk-C-Code ein Tcl_Obj siehst, dann ist es in Wirklichkeit ein stinknormaler Perl-SV (siehe Definition in tkGlue.def: ). Entsprechend sind alle Tcl*-Funktionen Aufrufe der äquivalenten Perl-Funktionen.

Quote

ich vermute auch das ist der grund der probleme mit multithreading in tcl.

Nein, soweit ich weiß, sind sowohl Tcl als auch Tk thread-safe und können mit Thread-Unterstützung kompiliert werden (jedenfalls interpretiere ich die FreeBSD-Port-Makefiles so). Es scheint so, als ob die Probleme eher im Perl-Glue liegen.

[quote=Strat,21.11.2005, 14:37]Und noch zur Groesse: ich habe in Perl/Tk schon groessere Applikationen geschrieben, meine letzte hatte etwa 16.000 Zeilen Code (ja, ich habe auch schleifen und subroutinen verwendet!), und es ging wunderbar.
[/quote]
Ich auch, und deshalb widerspreche ich lichtkind: man kann große Applikationen in Perl/Tk schreiben.

Quote

@ptk: ich arbeite momentan recht viel mit Tcl (8.3, da sind noch die meisten Perl-Einfluesse aussen vorgeblieben; die meisten kommen erst ab 8.4); ich gebe dir da voellig recht; ich habe da auch meine Probleme.

Ich habe sogar mal ein technisches Gutachten für ein Tcl/Tk-Buch von O'Reilly gemacht, und dennoch muss ich auch für die einfachsten Konstrukte immer wieder in die Manpages schauen. Es ist einfach nicht intuitiv genug.

Merkwürdigerweise ist Tk dafür um so intuitiver :-)

[quote=lichtkind,20.11.2005, 16:06]ich meinte das eigentlich anders, ich wollte wissen wie man in Tk in einen bereich was mit ogl reinrendert. das zinc ogl brauch um sowas zu machen ist bezeichnend denn in wx ist es nicht so, da ist ogl nativ schon eingebunden und es gibt DC = draw context wo man völlige freiheit darüber hat was wie gezeichnet wird und wann es erneuert wird. aber um das im detail zu besprechen würde ich gerne vorher etwas mehr zu tk wissen.[/quote]Inwieweit Tk::Zinc OpenGL-Features direkt ansprechen kann, weiß ich nicht. Man hat ja noch die andere Alternative (OpenGL-Modul in Tk einbetten). Aber inwieweit ist der Einsatz von OpenGL notwendig, um komplette große Anwendungen, wie, sagen wir mal, Textverarbeitungen, Editoren oder Tabellenkalkulationen zu schreiben?

Quote

Perls DWIM ist ja dazu da arbeit zu sparen was auch aufgabe einer bibliothek ist. da empfinde ich es etwas als kontaproduktiv zu sagen das es prinzipiell geht. tcl war ja anfangs auch rein stringbasierend entworfen und dann durch perl konkurenzdruck völlig umgearbeitet worden. ähnlich versuchen sie mit den umarbeiten und vielen erweiterungen aus tk etwas zu machen wofür es ursprünglich nicht gedacht war anstatt bei deren stärken zu bleiben.

Das ist eine der Ideen von Tcl und Tk: ein kleiner Kern, aber dafür leicht (in C) erweiterbar. Bei Perl/Tk ist die Entwicklung etwas anders gegangen: es gibt kaum Erweiterungen in C (da scheint die Hürde doch zu groß zu sein; außerdem sind viele Tk-Erweiterungen bereits im Perl/Tk-Core enthalten, so dass die Notwendigkeit gar nicht bestand), aber dafür ziemlich viele in Perl geschriebene Erweiterungen, weil die Erweiterung per Perl im Gegensatz zu Tcl/Tk früh standardisiert wurde (Tk::mega) und es durch die OO-Fähigkeiten von Perl sowieso leichter ist.

Quote

wx ist einfach die bessere basis, ohne tcl interpreter im hintergrund

Irrtum, schrieb ich bereits

Quote

, schneller(wx ist sehr auf geschwindigkeit optimiert programmiert) und auch mit mehr freiheit sachen zu erweitern, nur leider zwingt es einen in perl wie in c++ zu schreiben weil wxperl ein einfacher wrapper um die c++ bibliothek ist.

Genau das ist ein Kritikpunkt. Man hat eine schöne DWIM-Sprache, mit der man superschnell programmieren kann und wird dann von einer Bibliothek ausgebrenst, bei der man wie vor dreißig Jahren programmieren muss. Wenn es denn einen schöneren Wrapper für Wx gäbe, der z.B. an die Perl/Tk-API angelehnt wäre, dann wäre das Programmieren damit viel angenehmer.

Und wenn ich endlich WxPerl auf meiner FreeBSD-Maschine kompiliert bekomme, dann könnte ich wenigstens mal gucken, wie sich das Modul anfühlt :-(