Schrift
[thread]4691[/thread]

QT und Perl? (Seite 3)

Leser: 3


<< |< 1 2 3 4 >| >> 36 Einträge, 4 Seiten
youngalcapone
 2004-01-05 21:03
#46499 #46499
User since
2003-08-14
185 Artikel
BenutzerIn
[default_avatar]
[quote=ptk,05.01.2004, 12:24]Noch nicht erwaehnt in diesem Thread: Gtk fuer Perl. Das habe ich wenigstens zum Laufen bekommen.[/quote]
Dann erzähl doch was über deine Erfahrungen damit!

Auch interessieren würde mich ob man auch mit der Mozilla XUL GUI und Perl was machen könnte...
Crian
 2004-01-05 23:11
#46500 #46500
User since
2003-08-04
5866 Artikel
ModeratorIn
[Homepage]
user image
Kein Canvas-Widget? Klingt nach ko-Kriterium ^^
s--Pevna-;s.([a-z]).chr((ord($1)-84)%26+97).gee; s^([A-Z])^chr((ord($1)-52)%26+65)^gee;print;

use strict; use warnings; Link zu meiner Perlseite
Cremator
 2004-01-06 03:52
#46501 #46501
User since
2003-11-26
97 Artikel
BenutzerIn
[default_avatar]
Quote
Aber 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
Und 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.

Quote
Immerhin 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.

Quote
zu 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.

Quote
Es gibt kein Canvas-Widget.

Ja, und? Dafuer gibt es Bitmaps und den Device Context wxMemoryDC mit dem man in der Bitmap rumkrickeln kann.

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

Wobei 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?
ptk
 2004-01-06 13:26
#46502 #46502
User since
2003-11-28
3645 Artikel
ModeratorIn
[default_avatar]
[quote=Cremator,06.Jan..2004, 02:52]
Quote
Aber 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.

Quote
Quote
Und 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.

Quote
Quote
Immerhin 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.

Quote
Quote
zu 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
fuehrt meistens zum Erfolg (modulo Bugs).

Quote
Quote
Es 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.

Quote
Andersrum 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.

Quote
Wobei 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.
JW
 2004-01-06 18:31
#46503 #46503
User since
2003-08-04
467 Artikel
HausmeisterIn
[Homepage] [default_avatar]
Ich drängle mich mal kurz dazwischen, um eine Lanze für PerlQt zu brechen.
Das ursprüngliche PerlQt-Modul wurde von Ashley Winters erstellt und gepflegt. Es war allerdings nur für Qt2. Da die Trolle in letzter Zeit häufiger verbessert haben, lief die Entwicklung der Perl-Module hinterher. Mit SmokeQt kam dann ein Wrapper um die Qt-Lib auf den Markt, der die Anpassung an viele verschiedene Sprachen ermöglichte. Jetzt hat seit ca. 2 Jahren Germain Garand das Ruder wieder in die Hand genommen und die aktuellen Module für Qt3/SmokeQt geschrieben.
Qt läuft übrigens sehr stabil. ;) (Die KDE-Entwickler würden Trolltech auch aufs Dach steigen, wenn es anders wäre.)
Bei den Dresdner Mongers sind wir 2 Leute die sich intensiv mit PerlQt auseinandersetzen. Im Moment sind wir beim Erstellen eines deutschen Tutorials. Teile davon kann man hier bewundern (http://rcswww.urz.tu-dresden.de/~s1010824/perlqt/index.html)
Allerdings ist in den letzten Monaten die Arbeit etwas liegengeblieben.
(ausführliche Informationen zu PerlQt gibt es hier: http://perlqt.sourceforge.net/)

Ähnlich Delphi ist es möglich mit dem QT-Designer eine Oberfläche quasi als WYSIWYG zusammenzustellen, ein spezieller Compiler (puic) macht aus dieser Datei, dann Perl-Quelltext. Es kann genausogut auch C++ oder Python Quelltext erzeugt werden.
Mit dieser Möglichkeit für RAD beschäftige ich mich gerade ausführlicher (wird auch ein Kapitel im Tutorial) und es sieht vielversprechend aus.\n\n

<!--EDIT|JW|1073411463-->
ptk
 2004-01-07 12:51
#46504 #46504
User since
2003-11-28
3645 Artikel
ModeratorIn
[default_avatar]
[quote=youngalcapone,05.Jan..2004, 20:03][quote=ptk,05.01.2004, 12:24]Noch nicht erwaehnt in diesem Thread: Gtk fuer Perl. Das habe ich wenigstens zum Laufen bekommen.[/quote]
Dann erzähl doch was über deine Erfahrungen damit!
[/quote]
Der Grund fuer die Verwendung von Gtk war, dass es sich bei der Maschine um einen Linux/strongarm-Rechner handelte, wo das Selberkompilieren nicht ganz so einfach war (sprich: Crosscompilation erforderte). perl-Gtk war im Gegensatz zu perl/Tk verfuegbar, also habe ich es verwendet.

Die API von Gtk sieht C-lastiger als die API von Tk aus. Ich bin Aesthet, und eine Bibliothek fuer eine Skriptsprache sollte auch entsprechend aussehen.

Code: (dl )
    $mw->Button(-text => "Bla")->pack(-fill => "x")


entspricht mehr meiner Erwartungshaltung als:

Code: (dl )
1
2
3
4
     $hbox = new Gtk::HBox(0, 0);
$mw->add($hbox);
$button = new Gtk::Button "Bla";
$hbox->pack_start($button, 0, 0, 0);


(Fehler im Gtk-Code sind beabsichtigt, wer kann sich ohne Dokumentation merken, welche Parameter an welcher Position erwartet werden).

Das ist wohl auch der Grund, warum es fuer Gtk und Qt GUI-Builder gibt, und warum es bei Tk dort eher schlecht aussieht: eine GUI haendisch zu bauen ist bei Tk wesentlich einfacher als bei "normalen" Toolkits.

Gtk hat ebenfalls kein Canvas-Widget, so dass ich mit vorgefertigten Bildern arbeiten musste und bei Bedarf zusaetzliche Objekte reinzeichnen musste (also wieder Rastergrafik, keine Vektorgrafik). Leider gab es Memory Leaks, die auf der kleinen Maschine unertraeglich waren, so dass ich ein Upgrade von Gtk durchfuehren muesste. Da ich dabei aber Gtk selbst compilieren musste, habe ich das ganze Gtk-Projekt aufgegeben und es nochmal als Tk-Projekt gestartet.

Disclaimer: das war vor zwei oder drei Jahren. Neuere Versionen von Gtk haben diesen Memory Leak bestimmt nicht mehr. Ausserdem sind unter Gnome noch mehr Widgets fuer Gtk verfuegbar, zum Beispiel auch ein Canvas-Widget. Ich lese gerade, dass es auch einen Win32-Port gibt --- das hat man also mittlerweile auch geschafft!
Gast Gast
 2004-01-10 17:25
#46505 #46505
hi,

wo bekomme ich ein gutes Tutorial für Perl-Qt her? Ich finde nur immer kurze und ich möchte doch schon gerne etwas ausführlicher bescheid wissen.

danke -- Steve
Crian
 2004-01-10 20:19
#46506 #46506
User since
2003-08-04
5866 Artikel
ModeratorIn
[Homepage]
user image
Genau deswegen sind Jörg und Konsorten wohl beim Erstellen eines deutschen Tutorials ... (siehe oben).
Ich hab aber selbst keine Ahnung von Perl/Qt und hab mir auch den aktuellen Stand des Tutorials nicht angesehen.

[quote=JW,06.01.2004, 17:31]Im Moment sind wir beim Erstellen eines deutschen Tutorials. Teile davon kann man hier bewundern (http://rcswww.urz.tu-dresden.de/~s1010824/perlqt/index.html)
Allerdings ist in den letzten Monaten die Arbeit etwas liegengeblieben.
(ausführliche Informationen zu PerlQt gibt es hier: http://perlqt.sourceforge.net/)
[/quote]\n\n

<!--EDIT|Crian|1073758855-->
s--Pevna-;s.([a-z]).chr((ord($1)-84)%26+97).gee; s^([A-Z])^chr((ord($1)-52)%26+65)^gee;print;

use strict; use warnings; Link zu meiner Perlseite
Gast Gast
 2004-01-10 20:41
#46507 #46507
hmmm,

ja der Stand ist das Problem. Irgendwie werde ich da nicht richtig schlau draus. Bzw. ich möchte noch mehr drüber erfahren.

Steve
JW
 2004-01-12 12:28
#46508 #46508
User since
2003-08-04
467 Artikel
HausmeisterIn
[Homepage] [default_avatar]
Naja, keiner hat mehr Zeit im Überfluss. Steffen kann in den nächsten Semesterferien wieder einsteigen, und ich mußte gerade mit Curses posen. Aber es geht weiter.
Bis dahin kannst du dir eigentlich mit allen Dokumentationen weiterhelfen die es zu Qt gibt. Da das KDE-Projekt darauf aufbaut müßte es eigentlich reichlich Stoff zu "KDE + C++" geben (meiner Meinung nach sogar ein Buch von Kalle Dalheimer "Qt-Programmierung").
andere Tut's:
http://www.pl-forum.de/work/qt/qt2ws001.html
und hier
Bei google ist da entsprechend noch mehr zu finden.

Das Programmierprinzip ist für Perl das gleiche, selbst die Funktionsnamen wurden übernommen, man muß lediglich das führend Q der Funktionen durch Qt:: ersetzen.
Alles ist allerdings noch nicht in Perl::Qt implementiert.
Einen guten Einstieg vermitteln die beiliegenden Tutorial-Skripte und Beispiele.
Ein schönes Hilfsmittel ist auch die Qt-Shell, mit der man Live experimentieren kann. http://perlqt.sourceforge.net/dist/current/doc/images/pqtsh.png\n\n

<!--EDIT|JW|1073903576-->
<< |< 1 2 3 4 >| >> 36 Einträge, 4 Seiten



View all threads created 2003-12-18 16:34.