Hallo, ich beschäftige mich seit einigen Wochen schon mit Python. Nun suche ich eine grafische Oberfläche. Welche ist denn sehr gut Dokumentiert? wxpython ist leider nur sehr mau dokumentiert. Noch eine Frage, wie speichert Ihr Daten ab? In einer MySQL Datenbank? Gruss Michael _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
maillist@moevy.net schrieb:
ich beschäftige mich seit einigen Wochen schon mit Python. Nun suche ich eine grafische Oberfläche. Welche ist denn sehr gut Dokumentiert?
Qt. Ohne Wenn und Aber. Es gibt keine andere GUI Bibliothek, die in gleichem Maße * umfangreich (Widgets, XML, DB-Anbindung, ...) * plattformübergreifend * gut in verschiedene Plattformen integriert (native Mac/Windows) * gut dokumentiert * leicht zu bedienen * gut strukturiert ist. Hat natürlich auch einen wunderschönen Designer, mit dem du Oberflächen mit der Maus bauen kannst. GTK/Glade, wxPython und wie sie alle heißen, liegen um Längen (Längen!) dahinter. Nachteile von Qt: * nicht für Python entwickelt, sondern für C++ (man merkt das an ein paar Ecken), aber welche GUI-Bibliothek ist schon native-Python? * Version 4 ist noch(!) nicht für Python verfügbar, die Windows-Version steht aber erst ab dieser Version unter der GPL. Die Arbeit an V4 geht merklich voran, erste Vorabversionen sind bereits verfügbar.
Noch eine Frage, wie speichert Ihr Daten ab? In einer MySQL Datenbank?
Hängt davon ab, manchmal in einem Dictionary, manchmal in Objekten, manchmal in XML, manchmal in PostgreSQL, manchmal als Text, ... Solange du keine etwas genaueren Anforderungen hast, kannst du leider auch keine genaueren Auskünfte bekommen. Stefan _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Stefan Behnel schrieb:
maillist@moevy.net schrieb:
ich beschäftige mich seit einigen Wochen schon mit Python. Nun suche ich eine grafische Oberfläche. Welche ist denn sehr gut Dokumentiert?
Qt. Ohne Wenn und Aber. Es gibt keine andere GUI Bibliothek, die in gleichem Maße
* umfangreich (Widgets, XML, DB-Anbindung, ...) * plattformübergreifend * gut in verschiedene Plattformen integriert (native Mac/Windows) * gut dokumentiert * leicht zu bedienen * gut strukturiert
ist. Hat natürlich auch einen wunderschönen Designer, mit dem du Oberflächen mit der Maus bauen kannst. GTK/Glade, wxPython und wie sie alle heißen, liegen um Längen (Längen!) dahinter.
Nachteile von Qt:
* nicht für Python entwickelt, sondern für C++ (man merkt das an ein paar Ecken), aber welche GUI-Bibliothek ist schon native-Python? * Version 4 ist noch(!) nicht für Python verfügbar, die Windows-Version steht aber erst ab dieser Version unter der GPL. Die Arbeit an V4 geht merklich voran, erste Vorabversionen sind bereits verfügbar.
Noch eine Frage, wie speichert Ihr Daten ab? In einer MySQL Datenbank?
Hängt davon ab, manchmal in einem Dictionary, manchmal in Objekten, manchmal in XML, manchmal in PostgreSQL, manchmal als Text, ...
Solange du keine etwas genaueren Anforderungen hast, kannst du leider auch keine genaueren Auskünfte bekommen.
Ich habe im Web ein kleines Produktionsmanagement programmiert. Dies möchte ich nun auch nativ mit Python realisieren. Da habe ich in Foren rumgefragt und da hiese es das man das nicht mit mysql machen würde. Warum auch immer. Eine andere Antwort habe ich noch nicht bekommen. Michael
Stefan
_______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
On Sat, 29 Oct 2005 10:38:59 +0200, maillist@moevy.net wrote:
Ich habe im Web ein kleines Produktionsmanagement programmiert. Dies möchte ich nun auch nativ mit Python realisieren. Da habe ich in Foren rumgefragt und da hiese es das man das nicht mit mysql machen würde. Warum auch immer. Eine andere Antwort habe ich noch nicht bekommen.
Sofern man SQL braucht, nehme man DBAPI2. Dann kann's Dir wurscht sein, wo die Daten effektiv landen, bis auf den Installationszeitpunkt. Ciao, Jürgen _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Hallo Jürgen, On 2005-10-29 12:05, Juergen Hermann wrote:
On Sat, 29 Oct 2005 10:38:59 +0200, maillist@moevy.net wrote:
Ich habe im Web ein kleines Produktionsmanagement programmiert. Dies möchte ich nun auch nativ mit Python realisieren. Da habe ich in Foren rumgefragt und da hiese es das man das nicht mit mysql machen würde. Warum auch immer. Eine andere Antwort habe ich noch nicht bekommen.
Sofern man SQL braucht, nehme man DBAPI2. Dann kann's Dir wurscht sein, wo die Daten effektiv landen, bis auf den Installationszeitpunkt.
meiner Meinung nach ist das zu sehr vereinfacht. - Verschiedene Datenbanken verwenden unterschiedliche SQL-Dialekte, die sich subtil unterscheiden können. Die SQL-Anweisungen beim Übergang auf ein anderes Datenbanksystem zu ändern, kann fehleranfällig sein. - Verschiedene Datenbankadapter können, auch wenn sie sich prinzipiell an die DB-API halten, unterschiedliche Parameterübergabeformate verwenden (siehe http://www.python.org/peps/pep-0249.html , Abschnitt zu "paramstyle"). - Datenbankadapter können sich in den Exceptions unterscheiden, mit denen sie auf bestimmte Fehlersituationen reagieren. Theoretisch schreibt die DB-API zwar vor, wann welche Exceptions zu verwenden sind, aber mitunter verstehen die Autoren die DB-API-Dokumentation unterschiedlich. - Datenbanken unterscheiden sich in ihren Fähigkeiten. Was in einer geht, erzeugt bei einer anderen u. U. einen "NotSupportedError". - Wenn man eine bisher verwendete Datenbank im Nachhinein (z. B. aus Geschwindigkeits- oder Wartungsgründen) gegen eine andere austauschen muss, muss man normalerweise die Daten migrieren. Im Kern hast du schon Recht. Man sollte möglichst (wenn man überhaupt eine SQL-Datenbank verwenden will) Datenbankadapter nutzen, die sich an die DB-API halten. Aber daraus zu schließen, dass man bei der Verwendung einer anderen als der ursprünglich geplanten Datenbank womöglich nur die Import-Anweisung für das entsprechende Pythonmodul ändern muss, stimme ich nicht zu. :-) Viele Grüße Stefan _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Hallo Michael, On 2005-10-29 10:38, maillist@moevy.net wrote:
Noch eine Frage, wie speichert Ihr Daten ab? In einer MySQL Datenbank?
Hängt davon ab, manchmal in einem Dictionary, manchmal in Objekten, manchmal in XML, manchmal in PostgreSQL, manchmal als Text, ...
Solange du keine etwas genaueren Anforderungen hast, kannst du leider auch keine genaueren Auskünfte bekommen.
Ich habe im Web ein kleines Produktionsmanagement programmiert. Dies möchte ich nun auch nativ mit Python realisieren.
wenn ich dich richtig verstehe, hast du also schon ein funktionierendes System, nur nicht in Python? Was verwendest du denn _bisher_ zur Datenspeicherung? (Und: Falls das System so funktioniert, wie es jetzt ist, warum willst du es nach Python übertragen?)
Da habe ich in Foren rumgefragt und da hiese es das man das nicht mit mysql machen würde. Warum auch immer. Eine andere Antwort habe ich noch nicht bekommen.
"Dass man das nicht mit mysql machen würde" ist m. E. keine gute Begründung. ;-) Wenn ich etwas lese wie "das macht man so", bin ich erstmal misstrauisch (was aber auch nicht heißen muss, dass der Rat schlecht ist). Viel Erfolg und viele Grüße Stefan _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Stefan Schwarzer schrieb:
On 2005-10-29 10:38, maillist@moevy.net wrote:
Da habe ich in Foren rumgefragt und da hiese es das man das nicht mit mysql machen würde. Warum auch immer. Eine andere Antwort habe ich noch nicht bekommen.
"Dass man das nicht mit mysql machen würde" ist m. E. keine gute Begründung. ;-) Wenn ich etwas lese wie "das macht man so", bin ich erstmal misstrauisch (was aber auch nicht heißen muss, dass der Rat schlecht ist).
Na ja, MySQL hat nunmal einfach nur eine sehr begrenzte Unterstützung für gängige Datenbankfeatures wie Views, Stored Procedures und solche Sachen. Insofern kann ich verstehen, dass manche Menschen meinen "Das macht man nicht mit MySQL". Macht ja auch Sinn, wenn mensch bedenkt, dass PostgreSQL auch OpenSource ist *und* eigentlich alles kann, was eine Datenbank können sollte. PostgreSQL ist sogar in Python programmierbar (also intern, nicht nur per Datenbankschnittstelle)... Stefan _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Na ja, MySQL hat nunmal einfach nur eine sehr begrenzte Unterstützung für gängige Datenbankfeatures wie Views, Stored Procedures und solche Sachen. Insofern kann ich verstehen, dass manche Menschen meinen "Das macht man nicht mit MySQL". Macht ja auch Sinn, wenn mensch bedenkt, dass PostgreSQL auch OpenSource ist *und* eigentlich alles kann, was eine Datenbank können sollte. PostgreSQL ist sogar in Python programmierbar (also intern, nicht nur per Datenbankschnittstelle)...
zwar is es nett, das man in PG mit Python stored procedures schreiben kann - aber ich halte von den Dingern wenig bis nix. Zwar wird ORACLE nicht müde zu behaupten das alles in der DB erledigt werden kann (und muss) - aber die Durchsichtigkeit des Argumnets wird offensichtlich wenn man sich klar macht das die _pro_prozessor_und_leistung_selbigens_ ihre Lizenzgebühren verlangen.... IMHO verschmieren sowohl Trigger als auch SPs den Applikationscode über mehrere Schichten, was die Verständlichkeit von Code _extrem_ erschwert. Denn dann kann ich nicht einfach in den Quelltext sehen und verstehen. Und bei ACID-fähigen DBs finde ich das auch eh nicht wichtig - denn da ist die Notwendigkeit eine bestimmte Operation atomar ablaufen zu lassen nicht mehr da - man kann beliebig stückeln, und im Fehlerfall zurückrollen. MfG Diez _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
maillist@moevy.net schrieb:
ich beschäftige mich seit einigen Wochen schon mit Python. Nun suche ich eine grafische Oberfläche. Welche ist denn sehr gut Dokumentiert? wxpython ist leider nur sehr mau dokumentiert. Noch eine Frage, wie speichert Ihr Daten ab? In einer MySQL Datenbank?
Hi Michael! Da stellst hier ein Glaubensfrage, auf die ich dir nur mit Stichworten antworten kann. pyQT - scheint nicht schlecht zu sein, aber sobald du für dein Programm auch nur einen Cent bezahlt bekommen möchtest, will Trolltec Geld. Und das nicht wenig. TkInter - einfach und wird meist mit Python mitinstalliert. Leider sind die Möglichkeiten mit TkInter recht eingeschränkt. Einfache Oberflächen sind kein Problem, aber wenn es mehr sein sollte, würde ich es nicht nehmen. pyGTK - in Ansätzen, einfach zu programmieren. Die Dokumentation ist spitze. Aber, es fehlen ein paar Dinge, wie z.B. ein Grid-Widget. Es wurde dem TreeView-Widget sehr viel Macht verliehen. Man kann damit fast alles machen wie z.B. eine Listenansicht, oder eine Baumansicht... Leider gibt deshalb aber auch kein *einfaches* Listen-Widgets oder ein *einfaches* TreeView-Widget. MDI-Fenster sind mit GTK nicht oder nur schwer zu erstellen. (GTK war bis jetzt mein Favorit.) wxPython - Ist nicht so schlecht dokumentiert, wie du glaubst. Auf der wxPython-Website findest du einiges an Material. Die Demo ist auch nicht ohne. Wenn du dir die mal ansiehst, dann siehst du, was alles möglich ist und hast auch schon ein Codebeispiel dafür. Es enthält bereits Objekte, die für das Drucken und eine Druckvorschau verwendet werden können (plattformübergreifend :-) ). Ein funktionierendes Grid-Widget ist auch mit dabei. Es gibt ziemlich viele, einfach zu verwendende, Widgets. Man muss sich also nicht aus einem, sehr mächtigen, Widget alles selber zusammenbasteln, sondern verwendet für jede "einfache Sache" auch ein "einfaches Widget". Das Beste daran ist, dass diese Widgets sowohl unter Windows wie auch unter Linux super aussehen. (wxPython wird wahrscheinlich mein Favorit werden, da die Möglichkeiten wirklich nicht schlecht sind.) Und jetzt zum Speichern: Python macht es einem sehr einfach, Daten als einfache Textdatei ins Dateisystem zu speichern. Es gibt **nichts schnelleres**, um ein *paar* Daten abzuspeichern und wieder darauf zuzugreifen. Der Nachteil an diesem System ist aber, wenn sich die gewünschte Information in einer größeren Datei befindet, dann muss Python zuerst die ganze Datei laden um auf die Information zugreifen zu können. Wenn eine Datei alle Daten enthält und diese Datei nur einmal eingelesen werden muss, dann ist eine einfache Textdatei an Geschwindigkeit nicht zu unterschätzen. - einfache Textdatei - einfache Textdatei mit Struktur --> pyYAML (YAML), XMarshaL (XML) oder optparse (INI) Noch schneller geht es, wenn du kein Textformat sondern ein Binärformat verwendest. Zu diesem Thema siehst du dir am besten "Pickle" an. Aber auch bei einem normalen Binärformat ist es immer noch so, dass die gesamte Datei eingelesen werden muss, um zu den Daten zu kommen. Ausgenommen du hast ein ausgeklügeltes System, mit dem du dir merkst, wo genau in der Binärdatei sich die gewünschten Daten befinden. Dann wären wir aber beim Thema Datenbanken, das ich weiter unten erkläre. Wenn du also viel Daten hast, auf die du nicht im Ganzen, sondern meistens nur teilweise zugreifen möchtest, dann bist du mit einer Datenbank gut beraten. Bei Datenbanken ist es meist so, dass ein Serverdienst im Hintergrund auf Anfragen von einem Programm wartet. Dieser Serverdienst ist normalerweise darauf optimiert, aus vielen Daten, wenig Informationen herauszufischen. Das können Datenbanksysteme wirklich gut. Wenn du aber sehr viele Informationen auf einmal haben möchtest, dann ist von einer Datenbank abzuraten. Diese sind nicht darauf optimiert. Es gibt eine kleine Datenbankschnittstelle, die mit wenig Daten und auch mit mittelgroßem Datenaufkommen gut klar kommt --> pySQLite. pySQLite kannst du verwenden, wenn du mit SQL gut klar kommst und in deinem Programm deine Daten gerne mit SQL verwalten möchtest. Ein paar hundert Megabyte sollten für pySQLite kein Problem darstellen. Sollten aber mehrere Programme bzw. Computer auf die gleichen Daten, evt. sogar gleichzeitig, zugreifen können, dann empfehle ich dir einen richtigen Datenbankdienst wie z.B. PostgreSQL oder MySQL. MySQL ist schnell und einfach. PostgreSQL ist wahrscheinlich nicht so schnell wie MySQL, kann aber mehr und ist auf Serverebene besser programmierbar. (z.B. gespeicherte Prozeduren, Beziehungen zwischen Tabellen, Views, Trigger, ...) Willst du einen stabilen Datenbankserver, dann verwende PostgreSQL, denn meine Warenwirtschaft würde ich MySQL NICHT anvertrauen. Das MySQL, welches unter kommerzieller Lizenz steht, ist zwar etwas besser, aber dafür kostet es auch Geld. mfg Gerold :-) -- ________________________________________________________________________ Gerold Penz - bcom - Programmierung gerold.penz@tirol.utanet.at | http://gerold.bcom.at | http://sw3.at Ehrliche, herzliche Begeisterung ist einer der wirksamsten Erfolgsfaktoren. Dale Carnegie _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Gerold Penz schrieb:
maillist@moevy.net schrieb:
ich beschäftige mich seit einigen Wochen schon mit Python. Nun suche ich eine grafische Oberfläche. Welche ist denn sehr gut Dokumentiert? wxpython ist leider nur sehr mau dokumentiert.
Da stellst hier ein Glaubensfrage.
Stattgegeben. Trotzdem, ich habe noch niemanden kennengelernt, der auf Qt umgestiegen ist und danach dann wieder etwas anderes benutzt hat (zumindest nicht aus freien Stücken).
pyQT - scheint nicht schlecht zu sein, aber sobald du für dein Programm auch nur einen Cent bezahlt bekommen möchtest, will Trolltec Geld. Und das nicht wenig.
Ansichtssache. Eigentlich sind die Preise doch recht moderat. Und wer wirklich nur einen Cent verdienen möchte, der sollte sich vielleicht überlegen, ob es das dann überhaupt wert ist...
TkInter - einfach und wird meist mit Python mitinstalliert. Leider sind die Möglichkeiten mit TkInter recht eingeschränkt. Einfache Oberflächen sind kein Problem, aber wenn es mehr sein sollte, würde ich es nicht nehmen.
Das ist klar der Vorteil: Überall installiert. Das war's dann aber auch schon. Insbesondere fehlt die WYSIWYG Erstellung von Oberflächen. Bei allem, was von der Komplexität her über ein "Hallo Welt!" hinaus geht, wird so etwas ziemlich schnell unersetzlich. Oberflächen wachsen, nicht vergessen!
pyGTK - in Ansätzen, einfach zu programmieren. Die Dokumentation ist spitze. Aber, es fehlen ein paar Dinge, wie z.B. ein Grid-Widget. Es wurde dem TreeView-Widget sehr viel Macht verliehen. Man kann damit fast alles machen wie z.B. eine Listenansicht, oder eine Baumansicht... Leider gibt deshalb aber auch kein *einfaches* Listen-Widgets oder ein *einfaches* TreeView-Widget. MDI-Fenster sind mit GTK nicht oder nur schwer zu erstellen. (GTK war bis jetzt mein Favorit.)
Ich habe PyGTK ausprobiert und bin (trotz 15 Jahren Programmiererfahrung, auch in vielen GUI-Sprachen) an den TreeViews gescheitert. Die sind dermaßen kompliziert, dass es für mich weniger Aufwand war, danach Qt zu lernen, als GTK-TreeViews einzusetzen. So bin ich überhaupt erst zu Qt gekommen. Größter Nachteil von GTK aber: Die Aufteilung in x Einzelbibliotheken, deren verschiedene Versionen alle untereinander inkompatibel sind. Pango ist noch das furchtbarste. Ich habe unter Linux noch nie mit einer Bibliothek dermaßen viele Probleme gehabt wie mit Pango. Ein Update und alle GTK-Anwendungen sind tot. Dann heißt es nachschauen, welche Bibliotheken mit welchen kompatibel sind, um wieder ein lauffähiges System zusammenzustellen (also nicht nur GTK wieder zum Laufen zu bringen, sondern auch passende wxWidgets und wxPython Versionen zu finden, etc.) Grauenvoll. Ich hätte nie gedacht, dass es unter Linux etwas vergleichbares gibt wie die "DLL-Hell" von Windows. Und GTK ist wohl auch das einzige Beispiel. Qt ist binärkompatibel über alle Versionen von Qt1 bis Qt3. Punkt. Qt4 war von Anfang an als Bruch der Kompatibilität geplant. Qt3 wird weiter supportet und Qt4 enthält vieles, was den Umstieg bei Bedarf erleichtert.
wxPython - Ist nicht so schlecht dokumentiert, wie du glaubst. Auf der wxPython-Website findest du einiges an Material. Die Demo ist auch nicht ohne. Wenn du dir die mal ansiehst, dann siehst du, was alles möglich ist und hast auch schon ein Codebeispiel dafür. Es enthält bereits Objekte, die für das Drucken und eine Druckvorschau verwendet werden können (plattformübergreifend :-) ). Ein funktionierendes Grid-Widget ist auch mit dabei. Es gibt ziemlich viele, einfach zu verwendende, Widgets. Man muss sich also nicht aus einem, sehr mächtigen, Widget alles selber zusammenbasteln, sondern verwendet für jede "einfache Sache" auch ein "einfaches Widget". Das Beste daran ist, dass diese Widgets sowohl unter Windows wie auch unter Linux super aussehen. (wxPython wird wahrscheinlich mein Favorit werden, da die Möglichkeiten wirklich nicht schlecht sind.)
Vorteile von wxWidgets/wxPython: * sehr vollständig * plattformübergreifend Nachteile von wxPython: * Läuft (bevorzugt) mit GTK. Großer Nachteil, s.o. * Inkompatibilitäten zwischen versch. Versionen * Ist in keiner Version, die ich bisher getestet habe, stabil. Segfaults waren bei meinen Tests nicht allzu selten. * WYSIWYG-Design Unterstützung ist zwar vorhanden, aber nicht berauschend. Ich habe mal Boa Constructor ausprobiert, war zwar brauchbar, aber genauso instabil wie wxPython selbst. Ehrlich, alles, wozu ich raten kann, ist Qt. Stefan _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Ehrlich, alles, wozu ich raten kann, ist Qt.
Ja und Amen. Und als Ergänzung: ich habe auch schon unter Windows die Qt-Free-Edition (Ein win-port der X11-Version) problemlos für einen Rollout verwendet. Wenn es also in-house-Entwicklungen sind, die man ja problemlos unter die GPL stellen kann - dann _immer_ Qt. Und ein MSDN-Abo kostet im Jahr auch 2K€ - etwa der Preis für eine Qt/PyQT-Einzehlentwicklerlizenz (wobei ich nicht weiss, was upgradesm kosten, die _sollten_ preiswerter sein, aber nichts genaues weiss ich nicht) MfG Diez _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Am Samstag, 29. Oktober 2005 13:13 schrieb Stefan Behnel:
Gerold Penz schrieb:
maillist@moevy.net schrieb:
ich beschäftige mich seit einigen Wochen schon mit Python. Nun suche ich eine grafische Oberfläche. Welche ist denn sehr gut Dokumentiert? wxpython ist leider nur sehr mau dokumentiert.
Da stellst hier ein Glaubensfrage.
Stattgegeben.
Trotzdem, ich habe noch niemanden kennengelernt, der auf Qt umgestiegen ist und danach dann wieder etwas anderes benutzt hat (zumindest nicht aus freien Stücken).
:-)
pyQT - scheint nicht schlecht zu sein, aber sobald du für dein Programm auch nur einen Cent bezahlt bekommen möchtest, will Trolltec Geld. Und das nicht wenig.
Ansichtssache. Eigentlich sind die Preise doch recht moderat. Und wer wirklich nur einen Cent verdienen möchte, der sollte sich vielleicht überlegen, ob es das dann überhaupt wert ist...
TkInter - einfach und wird meist mit Python mitinstalliert. Leider sind die Möglichkeiten mit TkInter recht eingeschränkt. Einfache Oberflächen sind kein Problem, aber wenn es mehr sein sollte, würde ich es nicht nehmen.
Das ist klar der Vorteil: Überall installiert. Das war's dann aber auch schon. Insbesondere fehlt die WYSIWYG Erstellung von Oberflächen. Bei allem, was von der Komplexität her über ein "Hallo Welt!" hinaus geht, wird so etwas ziemlich schnell unersetzlich. Oberflächen wachsen, nicht vergessen!
.. oder man nutzt sowas wie die Python Mega Widgets, die auf Tkinter aufsetzen, und stellt entsetzt fest, wie langsam GUIs werden können (gähn), abgesehen vom "Look" unter Linux "würg"..
pyGTK - in Ansätzen, einfach zu programmieren. Die Dokumentation ist spitze. Aber, es fehlen ein paar Dinge, wie z.B. ein Grid-Widget. Es wurde dem TreeView-Widget sehr viel Macht verliehen. Man kann damit fast alles machen wie z.B. eine Listenansicht, oder eine Baumansicht... Leider gibt deshalb aber auch kein *einfaches* Listen-Widgets oder ein *einfaches* TreeView-Widget. MDI-Fenster sind mit GTK nicht oder nur schwer zu erstellen. (GTK war bis jetzt mein Favorit.)
Ich habe PyGTK ausprobiert und bin (trotz 15 Jahren Programmiererfahrung, auch in vielen GUI-Sprachen) an den TreeViews gescheitert. Die sind dermaßen kompliziert, dass es für mich weniger Aufwand war, danach Qt zu lernen, als GTK-TreeViews einzusetzen. So bin ich überhaupt erst zu Qt gekommen.
Größter Nachteil von GTK aber: Die Aufteilung in x Einzelbibliotheken, deren verschiedene Versionen alle untereinander inkompatibel sind. Pango ist noch das furchtbarste. Ich habe unter Linux noch nie mit einer Bibliothek dermaßen viele Probleme gehabt wie mit Pango. Ein Update und alle GTK-Anwendungen sind tot. Dann heißt es nachschauen, welche Bibliotheken mit welchen kompatibel sind, um wieder ein lauffähiges System zusammenzustellen (also nicht nur GTK wieder zum Laufen zu bringen, sondern auch passende wxWidgets und wxPython Versionen zu finden, etc.) Grauenvoll. Ich hätte nie gedacht, dass es unter Linux etwas vergleichbares gibt wie die "DLL-Hell" von Windows. Und GTK ist wohl auch das einzige Beispiel.
Ich finde die zugrunde liegenden Konzepte auch bedenklich: da haben ein paar Köpfe eine C++ Allergie, die daraus resultierende C'e bzw. zähe OO wird als Vorteil verkauft, obwohl es die API uglifiziert, Typsicherheit wegwirft, Speicherverwaltung verkompliziert, und viele weitere kleine Hässlichkeiten impliziert, die ich, Gott sei Dank, verdrängt habe. Was im Linuxkernel noch gut funktioniert, gilt auf jeden Fall nicht für das GUI. Jeder, der mit einem Toolkit anfangen will, sollte sich die zugehörigen Bibliotheken einmal selber bauen, um zu verstehen, worauf er sich einläßt.
Qt ist binärkompatibel über alle Versionen von Qt1 bis Qt3. Punkt. Qt4 war von Anfang an als Bruch der Kompatibilität geplant. Qt3 wird weiter supportet und Qt4 enthält vieles, was den Umstieg bei Bedarf erleichtert.
Durch richtige OO ist die Struktur nachvollziehbar, und vorhersagbar (predictable). Das macht eine so große Bibliothek überhaupt erst sinnvoll nutzbar. Daneben sind noch volle i18n/Unicode Unterstützung erwähnenswert.
wxPython - Ist nicht so schlecht dokumentiert, wie du glaubst. Auf der wxPython-Website findest du einiges an Material. Die Demo ist auch nicht ohne. Wenn du dir die mal ansiehst, dann siehst du, was alles möglich ist und hast auch schon ein Codebeispiel dafür. Es enthält bereits Objekte, die für das Drucken und eine Druckvorschau verwendet werden können (plattformübergreifend :-) ). Ein funktionierendes Grid-Widget ist auch mit dabei. Es gibt ziemlich viele, einfach zu verwendende, Widgets. Man muss sich also nicht aus einem, sehr mächtigen, Widget alles selber zusammenbasteln, sondern verwendet für jede "einfache Sache" auch ein "einfaches Widget". Das Beste daran ist, dass diese Widgets sowohl unter Windows wie auch unter Linux super aussehen. (wxPython wird wahrscheinlich mein Favorit werden, da die Möglichkeiten wirklich nicht schlecht sind.)
Vorteile von wxWidgets/wxPython: * sehr vollständig * plattformübergreifend
Nachteile von wxPython: * Läuft (bevorzugt) mit GTK. Großer Nachteil, s.o. * Inkompatibilitäten zwischen versch. Versionen * Ist in keiner Version, die ich bisher getestet habe, stabil. Segfaults waren bei meinen Tests nicht allzu selten. * WYSIWYG-Design Unterstützung ist zwar vorhanden, aber nicht berauschend. Ich habe mal Boa Constructor ausprobiert, war zwar brauchbar, aber genauso instabil wie wxPython selbst.
Korrekt, aber was m.E. das schlimmste ist, daß die so genannte Plattformunabhängigkeit konterkariert wird durch Abweichungen im Verhalten der Widgets zwischen den Plattformen, was dazu führt, daß immer alle Aspekte eines GUI auf allen Plattformen getestet werden muß, und letztendlich zu einer Menge plattformabhängigen Anpassungen führt, solange bis man es leid ist... (Gleichung mit zu vielen Variablen/Unbekannten)
Ehrlich, alles, wozu ich raten kann, ist Qt.
+1
Stefan
Pete _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
On 29.10.05 14:49:08, Hans-Peter Jansen wrote:
Am Samstag, 29. Oktober 2005 13:13 schrieb Stefan Behnel:
Qt ist binärkompatibel über alle Versionen von Qt1 bis Qt3. Punkt.
Sicher? Ich denke nicht, innerhalb der Major Release Qt1, Qt2 und Qt3 liefert Trolltech Binaerkompatibilitaet ja, aber ich denke nicht ueber Major Releases hinweg. Das wuerde bedeutet, dass die Klassen in Qt1 diesselben Methoden und Attribute haben wie in Qt3 und das glaub ich wirklich nicht...
Qt4 war von Anfang an als Bruch der Kompatibilität geplant. Qt3 wird weiter supportet und Qt4 enthält vieles, was den Umstieg bei Bedarf erleichtert.
Aehm, schonmal auf der qt-interest-Liste mitgelesen? Offensichtlich ist die Portierung eines Qt3-Programms auf Qt4 nicht nur "nicht einfach", sondern sogar so kompliziert, dass ein Rewrite einfacher ist. Qt4 ist IMHO immernoch in der Betaphase, aber vllt. wird das mit 4.1 besser...
Durch richtige OO ist die Struktur nachvollziehbar, und vorhersagbar (predictable).
Naja, es gibt in Qt3 auch so ein paar "Ungereimtheiten", insbesondere im Zusammenhang mit der QStringList, die eben keine QValueList<QString> ist...
Ehrlich, alles, wozu ich raten kann, ist Qt.
+1
+1 Andreas -- Your best consolation is the hope that the things you failed to get weren't really worth having. _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Hallo! Andreas Pakulat schrieb:
On 29.10.05 14:49:08, Hans-Peter Jansen wrote:
Am Samstag, 29. Oktober 2005 13:13 schrieb Stefan Behnel:
Qt ist binärkompatibel über alle Versionen von Qt1 bis Qt3. Punkt.
Sicher? Ich denke nicht, innerhalb der Major Release Qt1, Qt2 und Qt3 liefert Trolltech Binaerkompatibilitaet ja, aber ich denke nicht ueber Major Releases hinweg. Das wuerde bedeutet, dass die Klassen in Qt1 diesselben Methoden und Attribute haben wie in Qt3 und das glaub ich wirklich nicht...
Ein für Qt 1.0 geschriebenes Programm läuft im Allgemeinen auch mit Qt3. Das ist einfach der Vorteil von OO beim Design von GUI-Toolkits. Dass viele Dinge inzwischen ausgewechselt sind und manches veraltet oder aufs Abstellgleis geschoben, führt dann eben dazu, dass ein ordentlich für Qt3 geschriebenes Programm wohl nicht mehr mit Qt1 funktioniert. Aber das stellt in den wenigsten Fällen ein Problem dar.
Qt4 war von Anfang an als Bruch der Kompatibilität geplant. Qt3 wird weiter supportet und Qt4 enthält vieles, was den Umstieg bei Bedarf erleichtert.
Aehm, schonmal auf der qt-interest-Liste mitgelesen? Offensichtlich ist die Portierung eines Qt3-Programms auf Qt4 nicht nur "nicht einfach", sondern sogar so kompliziert, dass ein Rewrite einfacher ist.
Vielleicht, und das stützt ja meine Aussage. Es ist ja niemand gezwungen, zu Qt4 zu wechseln. Ebensowenig muss neue Software sich um Qt3 kümmern. Nur, wer mit Qt3-Software unbedingt die Möglichkeiten von Qt4 nutzen möchte, der darf sich das dann auch was kosten lassen. Trolltech hat nie einen Hehl daraus gemacht, dass der Umstieg nicht ohne Handarbeit gehen würde.
Durch richtige OO ist die Struktur nachvollziehbar, und vorhersagbar (predictable).
Naja, es gibt in Qt3 auch so ein paar "Ungereimtheiten", insbesondere im Zusammenhang mit der QStringList, die eben keine QValueList<QString> ist...
Was mir als Python Programmierer natürlich herzlich egal ist. Gruß, Stefan _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Qt ist binärkompatibel über alle Versionen von Qt1 bis Qt3. Punkt.
Sicher? Ich denke nicht, innerhalb der Major Release Qt1, Qt2 und Qt3 liefert Trolltech Binaerkompatibilitaet ja, aber ich denke nicht ueber Major Releases hinweg. Das wuerde bedeutet, dass die Klassen in Qt1 diesselben Methoden und Attribute haben wie in Qt3 und das glaub ich wirklich nicht...
Ein für Qt 1.0 geschriebenes Programm läuft im Allgemeinen auch mit Qt3. Das ist einfach der Vorteil von OO beim Design von GUI-Toolkits. Dass viele Dinge inzwischen ausgewechselt sind und manches veraltet oder aufs Abstellgleis geschoben, führt dann eben dazu, dass ein ordentlich für Qt3 geschriebenes Programm wohl nicht mehr mit Qt1 funktioniert. Aber das stellt in den wenigsten Fällen ein Problem dar.
Nenene, das stimmt mal garnicht. Da hat Andreas schon recht: binärkompatibliät geht nur zwischen Majors - und ist BTW verdammt schwierig zu garantieren in C++. Und die APIs haben sich zwischen Qt1-3 auch um einiges geändert - womöglich nicht so stark wie bei Qt4, aber etwas Handarbeit ist schon angesagt. MfG Diez _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Diez B. Roggisch schrieb:
Qt ist binärkompatibel über alle Versionen von Qt1 bis Qt3. Punkt.
Sicher? Ich denke nicht, innerhalb der Major Release Qt1, Qt2 und Qt3 liefert Trolltech Binaerkompatibilitaet ja, aber ich denke nicht ueber Major Releases hinweg. Das wuerde bedeutet, dass die Klassen in Qt1 diesselben Methoden und Attribute haben wie in Qt3 und das glaub ich wirklich nicht...
Ein für Qt 1.0 geschriebenes Programm läuft im Allgemeinen auch mit Qt3. Das ist einfach der Vorteil von OO beim Design von GUI-Toolkits. Dass viele Dinge inzwischen ausgewechselt sind und manches veraltet oder aufs Abstellgleis geschoben, führt dann eben dazu, dass ein ordentlich für Qt3 geschriebenes Programm wohl nicht mehr mit Qt1 funktioniert. Aber das stellt in den wenigsten Fällen ein Problem dar.
Nenene, das stimmt mal garnicht. Da hat Andreas schon recht: binärkompatibliät geht nur zwischen Majors - und ist BTW verdammt schwierig zu garantieren in C++.
Wobei es die Frage ist, was davon an Qt liegt und was am C++-Compiler. Nicht nur der GCC (insbesondere der g++/libstdc++) hat sich ja mit den Jahren um Größenordnungen gewandelt, die Binaries egal welcher Art inkompatibel machen. Wenn du den selben C++-Compiler nebst Stdlib und anderen Abhängigkeiten nimmst, mit dem du damals die Qt1 übersetzt hast, dann sollte das mit der Kompatibilität auch bei C++ hinhauen. Allerdings ist es dann meist doch einfacher, die Qt mit neu zu übersetzen, denn von dem Kompilat hätte sonst mangels alter libstdc++ auch niemand mehr was. Mit anderen Compilern habe ich da nicht genug Erfahrung. Aber ist auch egal, ich werde den Nachweis ohnehin nicht antreten. Eigentlich hat die Diskussion auch nichts auf der Python-Mailingliste zu suchen, da wäre dann die Kompatibilität von PyQt wichtiger. Und die ist dann wieder eine ganz andere Geschichte... Stefan _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Wobei es die Frage ist, was davon an Qt liegt und was am C++-Compiler. Nicht nur der GCC (insbesondere der g++/libstdc++) hat sich ja mit den Jahren um Größenordnungen gewandelt, die Binaries egal welcher Art inkompatibel machen. Wenn du den selben C++-Compiler nebst Stdlib und anderen Abhängigkeiten nimmst, mit dem du damals die Qt1 übersetzt hast, dann sollte das mit der Kompatibilität auch bei C++ hinhauen. Allerdings ist es dann meist doch
Nein. Das habe ich in de.c.l.py schon mal diskutiert, deswegen nur kurz: C++ ändert das Speicherlayout wenn man zB neue private Variablen einführt und dabei nicht höllsich aufpasst. Und das bei gleichem compiler. Damit bricht man binärkompatiblität - trolltech selber hat dazu mal einen Aufsatz verfasst, der erläutert wie man da vorgehen muss um das zu verhindern. Und das ist nicht zwischen Major revisions machbar. Sie habe wenn das API soweit mit Compatiblitätslayern versehen, das man eine alte Qt2-App noch unter 3 zum laufen bekommt - durch einen Compilationbslauf, und mit (verhältnismässig) wenig Änderungen. Was alles übrigens ein guter grund sein kann, C-style interface zu verwenden für eine Bibliothek, auch wenn sie intern mit C++ geschrieben wurde.
Aber ist auch egal, ich werde den Nachweis ohnehin nicht antreten. Eigentlich hat die Diskussion auch nichts auf der Python-Mailingliste zu suchen, da wäre dann die Kompatibilität von PyQt wichtiger. Und die ist dann wieder eine ganz andere Geschichte...
Das ist insofern von belang, als das pyQt ja für eine bestimmte Version kompliliert wurde. Wenn was du sagst stimmen würde, dann könnte man PyQT 3.x ja für Qt-1 benutzen usw. Und das geht eben nicht. Aber wenn man zusammen geschnürte Pakete nimmt, dann hat man damit natürlich nix zu tun. Und zumindest für den Desktop ist ja auch eigentlich nur noch Qt3 von Belang. MfG Diez _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Hallo! Diez B. Roggisch schrieb:
C++ ändert das Speicherlayout wenn man zB neue private Variablen einführt und dabei nicht höllsich aufpasst. Und das bei gleichem compiler. Damit bricht man binärkompatiblität - trolltech selber hat dazu mal einen Aufsatz verfasst, der erläutert wie man da vorgehen muss um das zu verhindern. Und das ist nicht zwischen Major revisions machbar. Sie habe wenn das API soweit mit Compatiblitätslayern versehen, das man eine alte Qt2-App noch unter 3 zum laufen bekommt - durch einen Compilationbslauf, und mit (verhältnismässig) wenig Änderungen.
Aha, also wieder was gelernt. Danke. Stefan _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Am Samstag, 29. Oktober 2005 18:36 schrieb Stefan Behnel:
Eigentlich hat die Diskussion auch nichts auf der Python-Mailingliste zu suchen, da wäre dann die Kompatibilität von PyQt wichtiger. Und die ist dann wieder eine ganz andere Geschichte...
um die es bzgl. Qt2 bis Qt3 recht ordentlich bestellt ist dank sip's eingebautem Versionshandling, d.h. auch die allerneueste PyQt-Version wird mit recht alten Qt-Versionen hinreichend funktionieren. Apropos sip: ist m.E. der einzige Wrapper, der direkt importierbare Bibliotheken erzeugt, also keine python stubs (mehr), und hat auch einige Tricks eingebaut, die speziell das Laden großer Klassenbibliotheken beschleunigen (lazy binding), d.h. from qt import * wird nicht mit übermäßiger Wartezeit und fettem Heap bestraft. Zum Vergleich: das letzte Mal, das ich WxPython übersetzt habe, mußte mal erst mal swig passend patchen, was dann nur mit veralteten Versionen funktionierte, und das Importieren dauerte Ewigkeiten. Pete _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Apropos sip: ist m.E. der einzige Wrapper, der direkt importierbare Bibliotheken erzeugt, also keine python stubs (mehr), und hat auch einige Tricks eingebaut, die speziell das Laden großer Klassenbibliotheken beschleunigen (lazy binding), d.h. from qt import * wird nicht mit übermäßiger Wartezeit und fettem Heap bestraft.
Zum Vergleich: das letzte Mal, das ich WxPython übersetzt habe, mußte mal erst mal swig passend patchen, was dann nur mit veralteten Versionen funktionierte, und das Importieren dauerte Ewigkeiten.
SIP ist auch IMHO das beste wrapper-Tool. SWIG ist eigentlich nur für C wirklich gut, bei C++ Objekten hat man immer noch die wrapper-klassen in Python zu schreiben. Und Pyrex habe ich zwar erst sehr rudimentär ausprobiert, aber letztlich scheint auch das eher C zu können. Ist trotzdem durch die recht gute Integration von C und Python sehr empfehlenswert - aber an SIP für C++ geht kein Weg vorbei. MfG Diez _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
On Sat, 29 Oct 2005 19:20:00 +0200, Diez B. Roggisch wrote:
... - aber an SIP für C++ geht kein Weg vorbei.
Guck mal genauer auf die Kreuzung und auf das spitze Schild mit der Aufschrift "boost::python" für den anderen Weg. ;) Ciao, Jürgen _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
On 29.10.05 18:08:07, Stefan Behnel wrote:
Andreas Pakulat schrieb:
On 29.10.05 14:49:08, Hans-Peter Jansen wrote:
Am Samstag, 29. Oktober 2005 13:13 schrieb Stefan Behnel:
Qt ist binärkompatibel über alle Versionen von Qt1 bis Qt3. Punkt.
Sicher? Ich denke nicht, innerhalb der Major Release Qt1, Qt2 und Qt3 liefert Trolltech Binaerkompatibilitaet ja, aber ich denke nicht ueber Major Releases hinweg. Das wuerde bedeutet, dass die Klassen in Qt1 diesselben Methoden und Attribute haben wie in Qt3 und das glaub ich wirklich nicht...
Ein für Qt 1.0 geschriebenes Programm läuft im Allgemeinen auch mit Qt3.
Mit ziemlicher Sicherheit tut es das nicht. Ich hab nur leider weder ein kompiliertes Qt2 noch Qt1 Programm um es zu testen... Du verwechselst hier Binaer mit Source-Kompatibilitaet. Ob Qt1-3 abwaerts-source-kompatibel sind, weiss ich nicht, aber abwaerts-binaer-kompatibel sind sie bestimmt nicht. Denn dann duerften sich die Variablenlisten genauso wie die Menge und Signaturen der virtuellen Funktionen nicht geaendert haben.
Das ist einfach der Vorteil von OO beim Design von GUI-Toolkits.
OO hat aber mit der Source oder Binaerkompatibilitaet wenig zu tun, ausser vllt. das C++-Bibliotheken wesentlich schwieriger Binaer-kompatibel zu halten sind als C-Bibliotheken.
Dass viele Dinge inzwischen ausgewechselt sind und manches veraltet oder aufs Abstellgleis geschoben, führt dann eben dazu, dass ein ordentlich für Qt3 geschriebenes Programm wohl nicht mehr mit Qt1 funktioniert.
Richtig, source-aufwaertskompatibilitaet wuerde bedeuten es wird kein Fortschritt im Design gemacht - das faellt eher unter Bugfix-Releases.
Qt4 war von Anfang an als Bruch der Kompatibilität geplant. Qt3 wird weiter supportet und Qt4 enthält vieles, was den Umstieg bei Bedarf erleichtert.
Aehm, schonmal auf der qt-interest-Liste mitgelesen? Offensichtlich ist die Portierung eines Qt3-Programms auf Qt4 nicht nur "nicht einfach", sondern sogar so kompliziert, dass ein Rewrite einfacher ist.
Vielleicht, und das stützt ja meine Aussage.
Wie gesagt, ich weiss nicht wie das beim Uebergang von Qt1 -> Qt2 -> Qt3 war (damals kannte ich dass noch nicht), aber beim Uebergang von Qt3 zu Qt4 ist nicht nur Binaerinkompatibilitaet gegeben sondern zusaetzlich auch noch Source und Design-Inkompatibilitaet hinzugekommen. Einige Dinge sind jetzt mit einem ganz anderen Programmier-Pattern geloest (z.B. die Model-View-Widgets).
Es ist ja niemand gezwungen, zu Qt4 zu wechseln.
Ich vermute auf lange Sicht schon, aber ein paar Monate/Jahre wird Qt3 wohl noch ueberleben...
Nur, wer mit Qt3-Software unbedingt die Möglichkeiten von Qt4 nutzen möchte, der darf sich das dann auch was kosten lassen.
?? Qt3 ist Qt3, wenn du deine Software komplett auf Qt4 umstellst, ist das quasi ein Rewrite - wie gesagt.
Trolltech hat nie einen Hehl daraus gemacht, dass der Umstieg nicht ohne Handarbeit gehen würde.
Das Problem ist aber: TT hatte extra fuer die "einfache" Migration die Q3-Support-Klassen mitgeliefert, sowie Tools um die Qt3-Programme zu konvertieren. Leider ist das Zeug so buggy dass man das ausfuehren der meisten Qt3-Programme mittels der Qt3-Support-Klassen vergessen kann und wirklich portieren muss auf Qt4. Da hat TT entweder zuviel PR-Arbeit der Form "Wir haben Qt3-Support-Klassen, damit Qt3-Apps einfach auf Qt4 weiterlaufen koennen" (entspricht Source-Kompatibilitaet) oder zuwenig QA bei den Klassen gemacht.
Durch richtige OO ist die Struktur nachvollziehbar, und vorhersagbar (predictable).
Naja, es gibt in Qt3 auch so ein paar "Ungereimtheiten", insbesondere im Zusammenhang mit der QStringList, die eben keine QValueList<QString> ist...
Was mir als Python Programmierer natürlich herzlich egal ist.
Hmm, wirklich? Was machst du wenn eine PyQt-Funktion dir eine QStringList zurueckliefert? Konvertierst du das erst in eine python-liste mit QStrings bzw. str? Ich gebe zu dass ich PyQt nicht ausreichend ausprobiert hab um auch mal zu schauen wie das mit den Containerklassen von Qt funktioniert... Andreas -- Living your life is a task so difficult, it has never been attempted before. _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Am Samstag, 29. Oktober 2005 16:59 schrieb Andreas Pakulat:
Aehm, schonmal auf der qt-interest-Liste mitgelesen? Offensichtlich ist die Portierung eines Qt3-Programms auf Qt4 nicht nur "nicht einfach", sondern sogar so kompliziert, dass ein Rewrite einfacher ist. Qt4 ist IMHO immernoch in der Betaphase, aber vllt. wird das mit 4.1 besser...
Ich werde auf jeden Fall so lange mit Qt4 warten, bis KDE4 einigermaßen läuft, bis dahin ist dann Phil mit PyQt4 auch so weit, und ich wette, für uns wird es wesentlich einfacher als für die C++er ;-) Was neben den neuen Klassen eine wirkliche Umstellung wird, ist das Fehlen von QString, da diese in PyQt4 vorraussichtlich durch native Python unicode Objekte ersetzt werden, d.h. Newcomer werden es einfacher haben, aber alte Hasen werden etwas brauchen, sich daran zu gewöhnen, die str() Funktion viel seltener zu brauchen, bzw. auf die .latin1() und .utf8() Methoden verzichten zu können/müssen.. Pete _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Hans-Peter Jansen schrieb:
Am Samstag, 29. Oktober 2005 16:59 schrieb Andreas Pakulat:
Aehm, schonmal auf der qt-interest-Liste mitgelesen? Offensichtlich ist die Portierung eines Qt3-Programms auf Qt4 nicht nur "nicht einfach", sondern sogar so kompliziert, dass ein Rewrite einfacher ist. Qt4 ist IMHO immernoch in der Betaphase, aber vllt. wird das mit 4.1 besser...
Ich werde auf jeden Fall so lange mit Qt4 warten, bis KDE4 einigermaßen läuft, bis dahin ist dann Phil mit PyQt4 auch so weit, und ich wette, für uns wird es wesentlich einfacher als für die C++er ;-)
Was neben den neuen Klassen eine wirkliche Umstellung wird, ist das Fehlen von QString, da diese in PyQt4 vorraussichtlich durch native Python unicode Objekte ersetzt werden, d.h. Newcomer werden es einfacher haben, aber alte Hasen werden etwas brauchen, sich daran zu gewöhnen, die str() Funktion viel seltener zu brauchen, bzw. auf die .latin1() und .utf8() Methoden verzichten zu können/müssen..
Ein Glück, dass mensch als vorausschauender (manche würden sagen: genervter) Programmierer da natürlich zwei schöne Funktionen pyqstr() und qstrpy() für geschrieben hatte, die in Qt4 dann einfach durch Dummies ersetzt werden können. Andere Anpassungen dürften da schwieriger werden... def qstrpy(qstring): return unicode(str(qstring.utf8()), 'utf-8') def pyqstr(ustring): return QString.fromUtf8( ustring.encode('utf-8') ) Gut, dass Geschwindigkeit in GUIs nachrangig ist... Stefan _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
participants (8)
-
Andreas Pakulat -
Diez B. Roggisch -
Gerold Penz -
Hans-Peter Jansen -
Juergen Hermann -
maillist＠moevy.net -
Stefan Behnel -
Stefan Schwarzer