Opened by skontox at 2003-12-18 16:34
User since
2003-11-28
3645 Artikel
ModeratorIn
![[default_avatar]](/battie/theme/default/default_avatar.gif)
2003-11-28
3645 Artikel
ModeratorIn
[quote=Cremator,06.Jan..2004, 02:52]
Genau das was ich sagte. Ich benutze momentan Perl 5.6.1 unter Win mit Tk 800.023 - ein paar Widgets/Controls sehen so aus wie man es von Win gewoehnt ist, aber z.B. das Optionmenu und einige andere sehen so aus wie unter X11/Motif und verhalten sich auch so (was extrem nervt).
[/quote]
Eine Liste aller problematischen Widgets, vielleicht mit Screenshots wie es aussehen muesste, waere hilfreich. Vielleicht kann ich da was machen... Mit Tk::BrowseEntry ist ein erster Schritt getan, mit -style => "MSWin32" sollte das Verhalten und Aussehen ziemlich nah am Original sein.
Font-Auswahl gibt es tatsaechlich nicht "nativ". Normalerweise behelfen sich die Leute, indem sie die jeweilige Win32::*-Funktion aufzurufen. Das koennte man verallgemeinern und in Tk::FontDialog integrieren. Das Fehlen von Druck und Preview ist ein Manko.
Meine Vorurteile kommen von der Benutzung von KDE, und KDE war bei meinen Versuchen bislang definitiv nicht stabil. Vielleicht ist es unter Linux/i386 stabil, aber nicht auf anderen Plattformen.
Man kann auch ganz gut ohne Gtk und KDE fahren --- ich habe zum Beispiel auf meiner Kiste kein aktuelles KDE und vermisse es auch nicht. Das Schoene an Perl/Tk ist, dass es keine Abhaengigkeiten hat (ausser X11-Libraries, aber die kann man ja ueberall voraussetzen).
fuehrt meistens zum Erfolg (modulo Bugs).
Nein. Auf Bitmaps rumkritzeln ist Rastergrafik, mit Tk-Canvas zu arbeiten ist Vektorgrafik. Das ist ein grosser Unterschied. Ich moechte in der Lage sein, beispielsweise einen Event-Listener auf eine Linie oder einen Kreis zu legen und dann entsprechend einen Tooltip anzeigen oder bei einem Klick eine bestimmte Aktion durchfuehren. Das geht vielleicht auch mit Rastergrafik, aber man muss die gemalten Objekte haendisch verwalten sowie die Berechnung der Objektbereiche fuer Events selbst durchfuehren.
Nein, bislang nicht. Wenigstens ist Tcl/Tk mittleweile (angeblich) Thread-safe, so dass eine Implementierung unter Perl/Tk jetzt theoretisch moeglich waere.
Mich macht es nervoes, wenn jede interne perl-Funktion mit einem zusaetzlichen Parameter fuer den aktuellen Thread-Kontext aufgerufen wird. Ich habe keine Benchmarks gemacht, aber dieser Parameter duerfte ein paar Prozent kosten --- bei *allen* Perl-Programmen, auch diejenigen, die keine Threads benutzen.
Man kann mit der jetzigen Implementierung keine tiefen Datenstrukturen (effizient) zwischen threads teilen. Bei allen meinen Ueberlegungen, Threads zu benutzen, war das ein Totschlag-Kriterium.
Interessant sind auch die Versuche von Elizabeth Mattijsen, threads produktiv einzusetzen (in der perl5-porters-Mailingliste nachzulesen). Das endete damit, dass sie mit forks.pm ein threads.pm-Replacement geschrieben hat --- unter Verwendung von fork.
Natuerlich sind meine Beschwerden ueber threads sehr Unix-zentrisch --- echte Prozesse unter Win32 zu erzeugen ist teuer, so dass man hier lieber Threads benutzt.
QuoteAber was meinst Du denn bei Tk mit halb Windows halb Motiv?
Genau das was ich sagte. Ich benutze momentan Perl 5.6.1 unter Win mit Tk 800.023 - ein paar Widgets/Controls sehen so aus wie man es von Win gewoehnt ist, aber z.B. das Optionmenu und einige andere sehen so aus wie unter X11/Motif und verhalten sich auch so (was extrem nervt).
[/quote]
Eine Liste aller problematischen Widgets, vielleicht mit Screenshots wie es aussehen muesste, waere hilfreich. Vielleicht kann ich da was machen... Mit Tk::BrowseEntry ist ein erster Schritt getan, mit -style => "MSWin32" sollte das Verhalten und Aussehen ziemlich nah am Original sein.
QuoteQuoteUnd die normalen Datei-Öffnen, Datei-Speicher, Farbwahl- und sonstwas Dialoge hat man unter Tk doch auch?!
Font-Auswahl und Druckvorschau unter Tk? Das waer mir neu. Auf jeden nicht bei meinem Perl, auch nicht direkt drucken.
Font-Auswahl gibt es tatsaechlich nicht "nativ". Normalerweise behelfen sich die Leute, indem sie die jeweilige Win32::*-Funktion aufzurufen. Das koennte man verallgemeinern und in Tk::FontDialog integrieren. Das Fehlen von Druck und Preview ist ein Manko.
QuoteQuoteImmerhin ist Tk um einiges aelter als Qt, allein deswegen glaube ich nicht, das Qt stabiler ist. Aber du hast nur was zu Qt allgemein gesagt und nichts zu PerlQt, und das wuerde mich mehr interessieren
Da ich hier auf der Win-Buechse rumwurste (und auf den ganzen cygwin-Schmodder keinen Bock mehr habe) kann ich da wenig zu sagen. Qt selber denke ich sollte bei der Menge Kohle die man dafuer hinlegen muss schon ziemlich stabil sein.
Meine Vorurteile kommen von der Benutzung von KDE, und KDE war bei meinen Versuchen bislang definitiv nicht stabil. Vielleicht ist es unter Linux/i386 stabil, aber nicht auf anderen Plattformen.
QuoteQuotezu viele externe Abhaengigkeiten
Kann ich mich unter Win nicht beklagen, da die Installation mit PPM problemlos funktioniert. Unter *nix hatte ich das noch nicht. Das Argument mit Abhaengigkeiten kann ich ehrlich gesagt auch nicht so ganz nachvollziehen. Je nachdem welche sonstige Software man einsetzen will, muss man frueher oder spaeter sowieso die Gtk- und die KDE-Libs auf die Muehle draufpacken. Ich wuerde dann eher auf KDE verzichten, da es fuer meinen Geschmack zu lahm ist, aber jeder wie er mag.
Man kann auch ganz gut ohne Gtk und KDE fahren --- ich habe zum Beispiel auf meiner Kiste kein aktuelles KDE und vermisse es auch nicht. Das Schoene an Perl/Tk ist, dass es keine Abhaengigkeiten hat (ausser X11-Libraries, aber die kann man ja ueberall voraussetzen).
Code: (dl
)
perl -MCPAN -e install Tk
QuoteQuoteEs gibt kein Canvas-Widget.
Ja, und? Dafuer gibt es Bitmaps und den Device Context wxMemoryDC mit dem man in der Bitmap rumkrickeln kann.
Nein. Auf Bitmaps rumkritzeln ist Rastergrafik, mit Tk-Canvas zu arbeiten ist Vektorgrafik. Das ist ein grosser Unterschied. Ich moechte in der Lage sein, beispielsweise einen Event-Listener auf eine Linie oder einen Kreis zu legen und dann entsprechend einen Tooltip anzeigen oder bei einem Klick eine bestimmte Aktion durchfuehren. Das geht vielleicht auch mit Rastergrafik, aber man muss die gemalten Objekte haendisch verwalten sowie die Berechnung der Objektbereiche fuer Events selbst durchfuehren.
QuoteAndersrum gefragt: Echtes Multithreading unter Tk? Geht das? So komplett mit Mutex-Absicherung? Ich hab nix darueber gefunden, waere also sehr dankbar wenn mich da jemand in die richtige Richtung schubsen koennte.
Nein, bislang nicht. Wenigstens ist Tcl/Tk mittleweile (angeblich) Thread-safe, so dass eine Implementierung unter Perl/Tk jetzt theoretisch moeglich waere.
QuoteWobei wir bei "Non-threaded Perl" waeren: Aeh.. wieso? Also jetzt ernsthaft. Warum kein multi-threaded Perl? Ist mir irgendwas entgangen? Resource-schonender als fork/Prozesse, leichter zu handhaben (meiner Meinung nach), warum also nicht?
Mich macht es nervoes, wenn jede interne perl-Funktion mit einem zusaetzlichen Parameter fuer den aktuellen Thread-Kontext aufgerufen wird. Ich habe keine Benchmarks gemacht, aber dieser Parameter duerfte ein paar Prozent kosten --- bei *allen* Perl-Programmen, auch diejenigen, die keine Threads benutzen.
Man kann mit der jetzigen Implementierung keine tiefen Datenstrukturen (effizient) zwischen threads teilen. Bei allen meinen Ueberlegungen, Threads zu benutzen, war das ein Totschlag-Kriterium.
Interessant sind auch die Versuche von Elizabeth Mattijsen, threads produktiv einzusetzen (in der perl5-porters-Mailingliste nachzulesen). Das endete damit, dass sie mit forks.pm ein threads.pm-Replacement geschrieben hat --- unter Verwendung von fork.
Natuerlich sind meine Beschwerden ueber threads sehr Unix-zentrisch --- echte Prozesse unter Win32 zu erzeugen ist teuer, so dass man hier lieber Threads benutzt.