Am Montag, 28. Februar 2022, 19:56:30 CET schrieb Stefan Ram:
> Hans-Peter Jansen <hpj(a)urpla.net> writes:
> >Wer ernsthaft grafische Beutzeroberflächen mit Python
> >programmieren will, kommt an PyQt nicht vorbei.
>
> Ich bin jedenfalls mit der in tkinter programmierten IDE
> "IDLE" sehr zufrieden. Diese kann ich auch leicht durch
> Modifikationen des Quellcodes an meine eigenen Vorstellungen
> anpassen (was ich mehrfach getan habe).
Nun, eric wird ordentlich maintained, und Detlev ist immer sehr kooperativ
gewesen, daher besteht diese Notwendigkeit für mich nicht, bzw. habe dafür
wirklich keine Zeit.
Habe mir die Python 3.10 Version von idle mal wieder angesehen, und was soll
ich sagen. Einen Vorteil haben die tk-Sachen ja: sie sehen überall hässlich
aus. Mein Sohn würde sagen, hey Papa, das ist so 90ies..
Na ja, die turtle graphics demo gefällt mir (hat aber ein Packaging-Problem
offenbart, dass ich gleich mal fixen werde..).
> Gerade wer als Anwender ernsthaft und effizient mit Software
> arbeitet, schätzt es, wenn diese schnell über eine Standard-
> oberfläche mit Menüs und Tastaturkürzeln zu bedienen ist.
> Vielleicht erlaubt Qt so etwas auch, und es ist lediglich
> so, daß es mehr von unterdurchschnittlichen Herstellern
> verwendet wird, die so etwas nicht in der Oberfläche bereitstellen.
Shortcuts sind 1st class member der Oberflächenkonzepte in Qt, und erfordern
in der Regel genau eine Zeile Code (Zuweisung eines Events zu einer Aktion).
Bei Menüs mit Shortcuts ist das gleich mit drin, und muss lediglich angegeben
werden.
Qt hat das Signals und Slots Konzept erfunden (soweit ich weiß), oder
zumindest in der GUI Programmierung etabliert, welches später von GTK
übernommen wurde, dort ist es aber nur übergestülpt (wie so vieles).
> >Lass Dir mal eine Datenbanktabelle mit 10000 Datensätzen
> >und 30 Feldern mit Tkinter anzeigen. Been there, done that.
> >No fun. Mit PyQt geht sowas, und läuft dann auch noch schnell
>
> Es ist meiner Meinung nach nicht unbedingt eine gute Idee,
> vielen Datensätze alle in die GUI zu kopieren/binden.
> Es gibt ja auch große Tabellen mit Milliarden von
> Datensätzen, und spätestens dann wird man sich das
> überlegen. Statt dessen könnte man immer nur die Datensätze,
> die gerade angezeigt werden sollen, in die GUI kopieren/binden.
>
> Ich finde mit einer Web-Suchmaschine Seiten mit Titeln wie:
>
> Why is Qt for Python so painfully slow even with a small table?
>
> PyQt QTableView prohibitively slow when scrolling with large data sets
>
> Slow initial show performance of QComboBox with large item count
>
> PyQT QTableWidget extremely slow - Stack Overflow
>
> PyQt5 Extremely Slow Scrolling on QTableView with pandas
>
> Qt UI slow to respond even after using threads - Stack Overflow
Interessant, ja, ich gebe zu, das MVC Paradigma ist nicht immer leicht zu
verstehen. Aber es gehört zu den leistungsfähigsten Prinzipien, um in einer
GUI effizient mit großen Datenmengen umzugehen. Der Trick ist, möglichst wenig
Python-Code zur Darstellung zu verwenden, womit dann große Teile mit C++ Speed
ausgeführt werden.
Ich habe sowas vor Urzeiten mit tkinter gemacht, musste dann aber alles zu Fuß
programmieren (blocked fetching from database, caching, virtual scroll area).
Bis das alles funktionierte, hat es gedauert.
In wxPython ging das schon besser, hakte dann aber in anderen Bereichen (z.B.
Plattform-Unterschiede unter Mac/Win/Linux).
In PyQt hat dies ca. 1/20 des tkinter Codes gebraucht, und wird mit
unfassbarer Geschwindigkeit ausgeführt, sieht viel besser aus, die Felder
können direkt editiert werden (wo gebraucht), dynamische/Benutzer
konfigurierbare Filterung ist auch kein Problem, und ist trotzdem viel weniger
Code.
Drucken ist tatsächlich etwas aufwändiger, da flexible Pagination sowie
überbreite Tabellen funktionieren müssen, aber Drucken ist immer eine
Herausforderung, wenn Sachen nicht einfach paginiert werden können, und
vielleicht auch noch gut aussehen sollen.
Beste Grüße,
Hans-Peter
--
Life without chameleons is possible, but pointless.
