[Python-de] Bilder bearbeiten mit PyQt

[Hans-Peter Jansen]

On Thursday 03 February 2005 04:18, Rudolf Liberda wrote:
> At 20:20 02.02.2005, Pete wrote:
>
> Bin soeben dabei eine GUI zu lernen, und bin desswegen sehr
> interessiert um wieviel leichter Du PyQt einschätzt im vergleich zu
> den anderen beiden. Kann es sein, dass die Lernkurve nach Tkinter
> und WxPython einfach besser ist? Ist es die Dokumentation, das
> vorhanden sein von Literatur oder wirklich der Aufbau von PyQt der
> Dich überzeugte.
> Rudolf

Naja, Tkinter hat ein paar nette Details, im Großen und Ganzen ist es 
aber:
 - umständlich zu programmieren
 - schnarchlahm
 - grottenhäßlich auf Linux [partiell kurierbar]
[Ich hoffe, niemanden damit persönlich zu beleidigen, aber das ist 
meine _Meinung_, und Ousterhout wird ja hier wohl nicht mitlesen]

WxPython ist da schon wesentlich besser, aber als ich vor zwei Jahren 
das Projekt verlies, haben mich folgende Sachen gestört:
 - die vers. GUI-Schichten machen es langsam (X->GTK->WxWin->WyPython) 
   besonders den Startup
 - auch die Struktur ist dadurch schwer zu durchschauen
 - man merkt dem Projekt die 20 Jahre, die es auf dem Buckel hat, an 
   besonders auf C++ Ebene, aber auch am API
 - python wrapper brauchten damals eine gepatchte SWIG Version:
   unsäglicher build, aufwändige Einbindung
 - Unterschiede im Verhalten vers. GUI Elemente machen die
   grundsätzlich vorhandene Crossplattform Fähigkeit wieder
   zunichte (Fokus, Selektionen)
 - Unbrauchbare Druckfunktion: alle Seiten werden in 24 bit Farbtiefe
   gewandelt, auch wenn 8bit Graustufen Images gedruckt werden:
   Ergebnis: ~45 MB pro Seite [als ich das erste Mal ein Fax gedruckt
   hatte, hab ich vielleicht Augen gemacht, als 2 Stunden später der
   Drucker tatsächlich was gedruckt hat...]
 - GUI Tools und i18n umständlich
 - Dokumentation unvollständig

Hier ein paar Gründe, warum ich dann bei PyQt gelandet bin:
 - die Basis stimmt: Klassenhierarchie, Umfang, Geschwindigkeit,
   Dokumentation, Tools, Support überzeugen weitgehend
 - die Einbindung stimmt: sip mausert sich zu einem echten Geheimtip,
   wenn es um das wrappen von C++ Klassenhierarchien geht:
   - seit sip4 wird alles in eine shared lib gepackt, keine
     Python Wrappermodule mehr notwendig (wie bei sip3 oder swig),
     dadurch minimaler Overhead, extrem dünne Bindungsschicht
   - delayed binding: der python Klassenraum entsteht beim ersten
     Zugriff, dadurch auch noch schnell bei Klassenmonstern wie Qt und 
     KDE, und schneller als vergleichbare Technologien
   - Unterschied der Startup-Zeit zwischen equivalenten C++ und Python
     Programmen nicht spürbar
   - sauberer Build
   - PyKDE, bzw. Jim Bublitz zeigt, wie weit man als einzelner mit
     sip/PyQt kommen kann: er wrappt praktisch ein komplettes KDE
     (zugegebenermaßen mit einem Trick: er benutzt ein Tool, um die
     sip Dateien zu erzeugen/upzudaten, anders wäre das als Hobbyist
     gar nicht zu schaffen..)
 - die Qt-API stimmt: wenn man die Struktur kapiert hat, kann man
   Methodennamen, Parameterreihenfolge, etc. praktisch erraten
 - die Tools überzeugen: auch wenn der Designer manchmal ein bißchen
   zickt, hat er einen wesentlichen Anteil an der Effizienz, Linguist
   (Übersetzung) und Assistant (Dokumentation) sind brauchbar
 - Eric ist der (Vorzeige-)Hammer
 - die Datenbankanbindung ist zugegebenermaßen etwas
   gewöhnungsbedürftig, ermöglicht mir aber inzwischen innerhalb von
   ein paar Tagen komplette Datenbankanwendungen aus dem Boden zu
   stampfen. 
 - Tabellen mit 50000 Datensätzen sind kein Problem [d.h. werden
   unverzögert angezeigt]. Auch wenn es eigentlich falsch ist, einem
   Benutzer eine Tabelle mit 2.5 Millionen Datensätzen zu zeigen 
   (nicht, daß man es nicht auch "richtig" machen kann), es geht (mit
   genug Speicher), braucht dann aber 650 MB/45 Sek. hier (11 Spalten,
   Server im LAN).. Don't try this with Tkinter ;-) 
 - Die Qt Literatur läßt sich durch die saubere Bindung gut verwenden

Für weitere PyQt Fragen und Projekte stehe ich gerne zur Verfügung.

Bis denne,
Pete