Generierung dynamischer QLineEdit-Felder abhängig vom User-Input

23 views
Skip to first unread message

Mohsen Owzar

unread,
Feb 22, 2022, 6:43:21 AMFeb 22
to
Hi liebe Python-Experte
Ich möchte in Python ein Programm schreiben, dass beliebige Daten in eine Datenbank platziert.
Zuerst fragt es den User nach dem Namen der Datenbank.
Wenn die angegebene Datenbank vorhanden ist, dann macht er nicht und bringt die Meldung, dass sie bereits vorhanden ist und neue Daten hineingefüllt werden können.
Wenn nicht, wird dann eine neue kreiert. Vorher wird aber gefragt, aus wie vielen Spalten (Elementen ausser ID) bestehen soll. Hierfür wird ein Dialogfenster geöffnet, das durch eine SpinBox die Anzahl der Spalten angegeben werden kann.
Im nachfolgenden Link aus meiner Repository habe ich zwei Python-Files abgelegt.
https://github.com/mohsen-owzar/dynamic_lineedits
Das eine File mit "_orig" im File-Namen habe ich beim Googeln gefunden, dass abhängig von dem eingestellten Wert der SpinBox genauso viele QLineedit-Felder erzeugt, deren Einträge mit "Apply"-Button auf die Konsole ausgegeben oder zu einer anderen Funktion übergeben werden können.
Ich wollte in dem anderen File meine Idee umsetzen, dass bei der Auswahl der Anzahl der Spalten der Datenbank in einem Eintrag statt jeweils einem QLineEdit, zwei QLineEdit-Felder oder QComboBoxes ausgegeben werden.
Alle meiner Versuche waren vergeblich und konnte nicht die Funktionalität der Original-Version mit meinen Wünschen hinzubekommen.
Als erstes soll der Unterschied beim Erscheinen der QLineEdit-Felder erwähnt werden, dass bei der Original-Version die Felder von oben nach unten erzeugt werden, während sie bei meiner Version von unten nach oben erscheinen. Es müsste irgendwie mit dem Befehl "addStetch(2)" auf Zeile 41 zu tun haben.
Ausserdem erscheint eine Fehlermeldung bei der Zahl "3" der QSpinBox (die ersten Male für "1" und "2" kommt keine Fehlermeldung), dass das Objekt keine Attribute "widget" besitzt, woraus ich nicht schlau werde. Nachfolgen ist die Fehlermeldung:
========================================================
Original exception was:
Traceback (most recent call last):
File "C:\Users\m.owzar\Desktop\QDialogs_Stuff\PythonScripts\lineedit_dynamic.py", line 70, in set_item_count
self.hbox[ii].itemAt(ii).widget().show()
AttributeError: 'NoneType' object has no attribute 'widget'
========================================================
Warum ich zwei QLineEdit-Felder oder QComboBoxes in meiner GUI haben möchte, liegt daran, dass bei der Datenbank-Generierung für jede zu erzeugende Spalte ein Feld für den Header und ein Feld für den Datentyp angegeben werden muss.
Und warum ich vielleicht auch QComboBox haben möchte, ist deswegen, dass der User aus verschieden Datentypen einen auszuwählen und nicht einzutippen braucht.
Ich wäre sehr dankbar und äussert glücklich, dass ein Python-Expert einen Blick auf mein Problem wirft, und mir sagt, wodurch meine Fehlermeldung entsteht und wie ich dieses Problem beheben kann.

Beste Grüsse
Mohsen Owzar

Jan

unread,
Feb 22, 2022, 2:23:10 PMFeb 22
to
Hi,

ich bin zwar kein Qt Experte, aber diese Zeilen schauen falsch aus:
#70 und #73.

Einmal das:
# Zeile 70
```self.hbox[ii].itemAt(ii).widget().show()```

# .itemAt(ii) - einmal zeigt "ii" auf "self.hbox" (findet etwas und dann
suchst du mit gleichem Wert von "ii" das "itemAt".

Zeile 73 hat auch diesen kleinen Fehler.

Ich bin mir nur nicht sicher ob du den Befehl wirklich brauchst,
vermutlich willst du immer 2 (zwei) Widgets einblenden. Also "linkes"
und "rechtes" QLineEdit oder deren übergeordneten Layout-Container.

Also, wenn du ".itemAt" brauchst dann eher so mit ".itemAt(0)" und
".itemAt(1)" für jeden "self.hbox[ii]"-Container.

LG

Jan

Mohsen Owzar

unread,
Feb 23, 2022, 4:29:26 AMFeb 23
to
Jan schrieb am Dienstag, 22. Februar 2022 um 20:23:10 UTC+1:
> Hi,
>
> ich bin zwar kein Qt Experte, aber diese Zeilen schauen falsch aus:
> #70 und #73.
>
> Einmal das:
> # Zeile 70
> ```self.hbox[ii].itemAt(ii).widget().show()```
>
> # .itemAt(ii) - einmal zeigt "ii" auf "self.hbox" (findet etwas und dann
> suchst du mit gleichem Wert von "ii" das "itemAt".
>
> Zeile 73 hat auch diesen kleinen Fehler.
>
> Ich bin mir nur nicht sicher ob du den Befehl wirklich brauchst,
> vermutlich willst du immer 2 (zwei) Widgets einblenden. Also "linkes"
> und "rechtes" QLineEdit oder deren übergeordneten Layout-Container.
>
> Also, wenn du ".itemAt" brauchst dann eher so mit ".itemAt(0)" und
> ".itemAt(1)" für jeden "self.hbox[ii]"-Container.
================================================
Hi Jan,
Danke für Deine rasche Antwort und, dass Du auch die zwei Zeilen im Visier genommen hast.
Ich denke auch, dass es an der Indizierung von hbox[ii] liegt, dass ich vielleicht ein nicht vorhandenes Objekt zeigen oder entfernen möchte. Ich habe versucht in PyCHarm zu debuggen, kam ich aber irgendwie nach einer Weile durcheinander und wusste nicht mehr, auf welches Objekt "ii" zeigt.
Ich glaube aber, dass diese zwei Zeilen unbedingt sein müssen, wie aus dem Original-File hervorgeht, das auch in meiner Git-Repository vorhanden ist.
Wie ich es verstanden habe, ist die Zeile 70 für den Fall, dass mit der SpinBox die Werte hochgezählt werden.
Bei jedem Hochzählen muss das neu entstandene QLineEdit-Feld (oder in meinem Fall zwei Edit-Felder) gezeigt werden, daher "widget().show()".
Und die Zeile 73 ist für jedes Herunterzählen, dass das vorhandene zuletzt hinzugefügte QLineEdit-Feld entfernt werden muss, daher "widget().hide()"
Ich werde aber weitersuchen und hoffe, dass auch noch jemand anders seinen Senf dazu gibt.
Das, was ich auch nicht verstanden habe, ist, warum bei der Originalversion die Felder von oben nach unten generiert werden, während bei mir umgekehrt von unten nach oben erscheinen.
Ich werde Deinen Vorschlag mit ".ItemAt(0)" auch ausprobieren.
LG
Mohsen

Hermann Riemann

unread,
Feb 23, 2022, 10:43:08 AMFeb 23
to
Am 22.02.22 um 12:43 schrieb Mohsen Owzar:

> File "C:\Users\m.owzar\Desktop\QDialogs_Stuff\PythonScripts\lineedit_dynamic.py", > line 70, in set_item_count
> self.hbox[ii].itemAt(ii).widget().show()
>AttributeError: 'NoneType' object has no attribute 'widget'
> mir sagt, wodurch meine Fehlermeldung entsteht > und wie ich dieses Problem beheben kann.

Diese Meldung besagt mit mit hoher Wahrscheinlichlichkeit
das self.hbox[ii].itemAt(ii) keinen Wert zugewiesen bekam.
Vor der Zeile ein print(ii) einfügen
und dann mit diesem Wert weiter vorne suchen.
Das zweite ii in obiger Zeile kommt mir allerdings verdächtig vor.

Hermann
der bei Fehlersuche des öfteren Ausgaben
in Test Dateien ( manchmal in html-Format) verwendet.

--
http://www.hermann-riemann.de

Hermann Riemann

unread,
Feb 23, 2022, 11:03:12 AMFeb 23
to
Am 23.02.22 um 08:00 schrieb Stefan Ram:

> Mit gewissen Vorbehalten sind folgende Werke für Anfänger geeignet:
> Introduction ..

Ich ziehe Bücher in deutsch vor.

Meist verwende ich Python 3 Rheinwerk Verlag(Ernesti Kaiser)
und Python3 mitp (eWigand)

Zur Weiterbildung momentan etwas "Effektiv Python programmieren"
(mitp Brett Slatkin)

Für Qt steht in obigen Bücher zwar etwas drin
aber für etliche Fälle muss ich mit google nach Funktionen suchen.

Mein einzige Python QT Experiment ist (vor Jahren) an Zuordnung
der Maus-Tastatur Kombination zu widges oder boxes gscheitert.

Hermann
der manchmal kleine Programme zur Text und Tabellen
Bearbeitung in Python3 schreibt.
( und überlegt die Lisp atom quote eval Funktionalität
aus Lisp in Python nachzubauen. )

--
http://www.hermann-riemann.de

Mohsen Owzar

unread,
Feb 23, 2022, 1:34:46 PMFeb 23
to
Hermann Riemann schrieb am Mittwoch, 23. Februar 2022 um 16:43:08 UTC+1:
> > mir sagt, wodurch meine Fehlermeldung entsteht > und wie ich dieses Problem beheben kann.
> Diese Meldung besagt mit mit hoher Wahrscheinlichlichkeit
> das self.hbox[ii].itemAt(ii) keinen Wert zugewiesen bekam.
> Vor der Zeile ein print(ii) einfügen
> und dann mit diesem Wert weiter vorne suchen.

Danke Hermann,
Ich habe Deinen Vorschlag befolgt und sogar für jede Variable eine Print-Anweisung am Anfang jeder FOR-Loop geschrieben.
Bei der ersten und der zweiten Erhöhung des SpinBox-Wertes kommen die Print-Anweisungen ohne Fehlermeldung heruas.
Sobald zum dritten Mal der Wert der SpinBox erhöht wird, erscheinzt die Fehlermeldung.
Es sieht aber alles gut aus. Warum er abstürzt, ist unklar.
Ich habe in meiner Git-Repository das File mit den Print-Anweisungen hinzugefügt. Du kannst es laufen lassen und sehen, dass nichts Ungewöhnliches ausgegeben wird.

> Das zweite ii in obiger Zeile kommt mir allerdings verdächtig vor.
Was meinst Du mit dem zweiten "ii in obiger Zeile"?
Du meinst das "ii" in den Klammern von "itemAt(ii)?

LG
Mohsen

Jan

unread,
Feb 23, 2022, 1:55:01 PMFeb 23
to


On 23.02.22 19:34, Mohsen Owzar wrote:
> Hermann Riemann schrieb am Mittwoch, 23. Februar 2022 um 16:43:08 UTC+1:
>>> mir sagt, wodurch meine Fehlermeldung entsteht > und wie ich dieses Problem beheben kann.
>> Diese Meldung besagt mit mit hoher Wahrscheinlichlichkeit
>> das self.hbox[ii].itemAt(ii) keinen Wert zugewiesen bekam.
>> Vor der Zeile ein print(ii) einfügen
>> und dann mit diesem Wert weiter vorne suchen.
>
> Bei der ersten und der zweiten Erhöhung des SpinBox-Wertes kommen die Print-Anweisungen ohne Fehlermeldung heruas.
> Sobald zum dritten Mal der Wert der SpinBox erhöht wird, erscheinzt die Fehlermeldung.
> Es sieht aber alles gut aus. Warum er abstürzt, ist unklar.

Es ist eigentlich "ganz einfach". Im ersten und zweiten durchlauf hat
das "ii" den Wert 0 und 1, dann 2, beim nächsten Schleifendurchlauf "3"
- das "item.at(2)" (2 == ii) wirft aber einen Fehler, weil nur 2 (zwei!)
Elemente in der "self.hbox[ii]" drin sind die aktuell gewählt ist - auf
Schleifenindex 0 und 1.

>> Das zweite ii in obiger Zeile kommt mir allerdings verdächtig vor.
> Was meinst Du mit dem zweiten "ii in obiger Zeile"?
> Du meinst das "ii" in den Klammern von "itemAt(ii)?
>

Genau das, das ItemAt hat den Wert 3 oder höher und du versuchsts auf
etwas zuzugreifen was nicht da ist.

Daher wäre es korrekt so - hier im Beispiel mit 3.
"self.hbox[3].itemAt(0).widget..."

Und so weiter.
Das "self.hbox" ist korrekt und wird auch gefunden. Das "itemAt(ii)" ist
falsch. Teste das mal mit "itemAt(0)" und oder "itemAt(1)" in der
gleichen Schleife. Und nicht mit "ii", das "ii" gilt nur für die
"self.hbox".

LG

Jan

Hermann Riemann

unread,
Feb 23, 2022, 9:27:10 PMFeb 23
to
Am 23.02.22 um 17:15 schrieb Stefan Ram:
> Hermann Riemann <nosp...@hermann-riemann.de> writes:
>> Mein einzige Python QT Experiment ist (vor Jahren) an Zuordnung
>> der Maus-Tastatur Kombination zu widges oder boxes gscheitert.
>
> Ich sehe hier unter Windows Programme, die anscheinend mit Qt
> geschrieben wurden.

Ich verwende kein windows mehr.
( Ich habe ein defektes windows XT
und irgendwo ein lahmer Laptop mit XP )
Android und apple habe ich vermieden.

Ich verwende Linux auf PCs mit KDE ( und raspberry pi .. )

> Leider unterstützen sie regelmäßig die
> üblichen Tastaturkürzel nicht und sind nur über die Zeigepfeil-
> Eingabe bedienbar. Daher würde ich so etwas nicht beim
> Programmieren verwenden, zumal mir tkinter gefällt. Erst kürzlich
> habe ich festgestellt, daß mit Pydroid 3 tkinter sogar unter
> Android verwendet werden kann.

GUI mache ich mit Python3 und cgi
Grafik mit C und SDL2
Python ist für Pixel Berechnungen zu langsam,
C für Textbearbeitung zu umständlich.
Eine Verbindung über "shared memory"
( Binärdatei unter tmpfs (RAM-disc) ) ist im Vorhaben.

--
http://www.hermann-riemann.de

Mohsen Owzar

unread,
Feb 25, 2022, 1:04:17 AMFeb 25
to
Jan schrieb am Mittwoch, 23. Februar 2022 um 19:55:01 UTC+1:

> Genau das, das ItemAt hat den Wert 3 oder höher und du versuchsts auf
> etwas zuzugreifen was nicht da ist.
>
> Daher wäre es korrekt so - hier im Beispiel mit 3.
> "self.hbox[3].itemAt(0).widget..."
>
> Und so weiter.
> Das "self.hbox" ist korrekt und wird auch gefunden. Das "itemAt(ii)" ist
> falsch. Teste das mal mit "itemAt(0)" und oder "itemAt(1)" in der
> gleichen Schleife. Und nicht mit "ii", das "ii" gilt nur für die
> "self.hbox".

Hi Jan,
Danke für Deine Eklärung, dass Du Licht ins Dunkeln brachtest.
Ich habe an der Stelle von dem zweiten "ii" eine "0" eingesetzt und es hat funktioniert.
Das, was ich immer nocht verstehe, wurum die Orignalversion mit dem zweiten "ii"funktioniert hat.
Ausserdem, warum erdcheinen bei mir die Edit-felder von unten und in der Originalversion von oben?

LG
Mohsen

Jan

unread,
Feb 25, 2022, 11:53:40 AMFeb 25
to


On 25.02.22 07:04, Mohsen Owzar wrote:
> Danke für Deine Eklärung, dass Du Licht ins Dunkeln brachtest.
> Ich habe an der Stelle von dem zweiten "ii" eine "0" eingesetzt und es hat funktioniert.

Gern geschehen. Schön das es jetzt funktioniert.

> Das, was ich immer nocht verstehe, wurum die Orignalversion mit dem zweiten "ii"funktioniert hat.

Schau mal hier:
# Zeile 50:
https://github.com/mohsen-owzar/dynamic_lineedits/blob/29e268f9b6c4f9539f6bc0ff856d802dce060c1a/lineedit_count_dynamically_orig.py#L50

# Zeile 50
self.item_layout.itemAt(ii).widget().show()

----

Im Item Layout wird das "ii" nur benutzt, um das Element "ii" über
"itemAt(ii)" anzusprechen. Bei dir hast du für jedes der zwei (2) Inputs
einen (1) Container "self.hbox" auf die du mit dem Counter "ii"
zugreifst. Daher funktioniert das auch im Original und bei dir so nicht.

> Ausserdem, warum erdcheinen bei mir die Edit-felder von unten und in der Originalversion von oben?
>
# Zeile 79
https://github.com/mohsen-owzar/dynamic_lineedits/blob/29e268f9b6c4f9539f6bc0ff856d802dce060c1a/lineedit_dynamic_with_prints.py#L79

#Zeile 79
""" for ii in range(self.item_count, new_count): """

----

Ich schätze es liegt daran, dass du den Zähler mit "self.item_count"
startest und nicht bei Null (0), 0 = "von vorne/oben" - so deute ich
zumnindest den Code.


LG

Jan


Mohsen Owzar

unread,
Feb 25, 2022, 12:08:57 PMFeb 25
to
Jan schrieb am Freitag, 25. Februar 2022 um 17:53:40 UTC+1:
> Schau mal hier:
> # Zeile 50:
> https://github.com/mohsen-owzar/dynamic_lineedits/blob/29e268f9b6c4f9539f6bc0ff856d802dce060c1a/lineedit_count_dynamically_orig.py#L50
>
> # Zeile 50
> self.item_layout.itemAt(ii).widget().show()
>
> Im Item Layout wird das "ii" nur benutzt, um das Element "ii" über
> "itemAt(ii)" anzusprechen. Bei dir hast du für jedes der zwei (2) Inputs
> einen (1) Container "self.hbox" auf die du mit dem Counter "ii"
> zugreifst. Daher funktioniert das auch im Original und bei dir so nicht.
> > Ausserdem, warum erdcheinen bei mir die Edit-felder von unten und in der Originalversion von oben?
> >
> # Zeile 79
> https://github.com/mohsen-owzar/dynamic_lineedits/blob/29e268f9b6c4f9539f6bc0ff856d802dce060c1a/lineedit_dynamic_with_prints.py#L79
>
> #Zeile 79
> """ for ii in range(self.item_count, new_count): """
>

Wow, jetzt sind die Groschen gefallen.

> Ich schätze es liegt daran, dass du den Zähler mit "self.item_count"
> startest und nicht bei Null (0), 0 = "von vorne/oben" - so deute ich
> zumnindest den Code.

OK, ich muss mich noch einmal damit beschäftigen, ob es wirklich so ist.

Ich bedanke mich noch einmal bei Dir für Deine Geduld.

LG
Mohsen

Hans-Peter Jansen

unread,
Feb 26, 2022, 12:39:51 PMFeb 26
to
Am Mittwoch, 23. Februar 2022, 17:15:53 CET schrieb Stefan Ram:
> Hermann Riemann <nosp...@hermann-riemann.de> writes:
> >Mein einzige Python QT Experiment ist (vor Jahren) an Zuordnung
> >der Maus-Tastatur Kombination zu widges oder boxes gscheitert.
>
> Ich sehe hier unter Windows Programme, die anscheinend mit Qt
> geschrieben wurden. Leider unterstützen sie regelmäßig die
> üblichen Tastaturkürzel nicht und sind nur über die Zeigepfeil-
> Eingabe bedienbar. Daher würde ich so etwas nicht beim
> Programmieren verwenden, zumal mir tkinter gefällt. Erst kürzlich
> habe ich festgestellt, daß mit Pydroid 3 tkinter sogar unter
> Android verwendet werden kann.

Come on, wenn man wegen persönlicher Präferenzen oder sonstigen Schwächen PyQt
nicht mag, kein Problem.

Dann aber öffentliche Foren dazu nutzen, diese Meinung als Qualitätsurteil zu
verbreiten, ist nicht okay. Besonders weil es letztlich auf die Qualität
dieser Liste, bzw. seiner Benutzer zurückfällt.

PyQt ist ein extrem effizientes Binding der äußerst umfangreichen Qt
Klassenbiliothek mit mehreren tausend Klassen und entsprechend vielen
Methoden.

Wer ernsthaft grafische Beutzeroberflächen mit Python programmieren will,
kommt an PyQt nicht vorbei.

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 (ohne das man sich selber die Finger brechen muss
mit query slicing, delayed load und so weiter).

Klar ist die inhärente Komplexität nicht jedermanns Sache, aber daraus
generelle Aussagen machen, sagt mehr über den Originator denn das Produkt aus.

Beispiele gefällig: eric: in PyQt entwickelte Entwicklungsumgebung, Calibre:
de-facto Standard für eBooks: Reader und Universalwerkzeugkasten.

Beste Grüße,
Hans-Peter
--
Life without chameleons is possible, but pointless.


Hermann Riemann

unread,
Feb 27, 2022, 2:34:50 AMFeb 27
to
Am 26.02.22 um 18:39 schrieb Hans-Peter Jansen:
> Am Mittwoch, 23. Februar 2022, 17:15:53 CET schrieb Stefan Ram:
>> Hermann Riemann <nosp...@hermann-riemann.de> writes:
>>> Mein einzige Python QT Experiment ist (vor Jahren) an Zuordnung
>>> der Maus-Tastatur Kombination zu widges oder boxes gscheitert.
>>
>> Ich sehe hier unter Windows Programme, die anscheinend mit Qt
>> geschrieben wurden. Leider unterstützen sie regelmäßig die
>> üblichen Tastaturkürzel nicht und sind nur über die Zeigepfeil-
>> Eingabe bedienbar. Daher würde ich so etwas nicht beim
>> Programmieren verwenden, zumal mir tkinter gefällt. Erst kürzlich
>> habe ich festgestellt, daß mit Pydroid 3 tkinter sogar unter
>> Android verwendet werden kann.
>
> Come on, wenn man wegen persönlicher Präferenzen oder sonstigen Schwächen PyQt
> nicht mag, kein Problem.
>
> Dann aber öffentliche Foren dazu nutzen, diese Meinung als Qualitätsurteil zu
> verbreiten, ist nicht okay. Besonders weil es letztlich auf die Qualität
> dieser Liste, bzw. seiner Benutzer zurückfällt.

Ich habe vor Jahren nicht nicht aktuell geschrieben.

> PyQt ist ein extrem effizientes Binding der äußerst umfangreichen Qt
> Klassenbiliothek mit mehreren tausend Klassen und entsprechend vielen
> Methoden.

Als Gelegenheits- und nicht Berufsprogrammierer
werde ich das sicher nicht ganz durchlesen,
sondern ich möchte nur soviel ausreichend einfach finden,
in dem ich das, was ich machen will, auch durchführen kann.

> Wer ernsthaft grafische Beutzeroberflächen mit Python programmieren will,
> kommt an PyQt nicht vorbei.

Doch, er könnte SDL (pygame) verwenden.
Und dann gibt es noch PyGtk.

> Lass Dir mal eine Datenbanktabelle mit 10000 Datensätzen und 30 Feldern mit
> Tkinter anzeigen.

Datenbanken verwende ich nicht.
Ich vermute, die Zugriffsgeschwindigkeit auf Datenbanken
hängt nicht von QT ab.
Tabellen zeige ich mittels html table per browser an,
wobei die html Seiten mit Python erstellt werden.
Derartiges habe ich ( mit cgi ) auch schon für Anwendungen verwendet,
die ich für andere Personen eingesetzt habe.
Statt Datenbanken verwende ich ( 1 Personen Betrieb )
csv ähnlich Dateien.

> Beispiele gefällig: eric: in PyQt entwickelte Entwicklungsumgebung, Calibre:
> de-facto Standard für eBooks: Reader und Universalwerkzeugkasten.

Als Entwicklungsumgebung für Python
verwende ich Linux bash, kate ,und ein kleines (Python3) Programm,
welches:
\t durch blanks ersetzt,
Zeilen jeweils durch zeile.rstrip()+'\n' ersetzt,
Leerzeilen am Dateiende löscht + eine hinzufügt
Zeilen auf ein vielfaches von 3 ausrichtet ( nicht 4, da privat )
und bei (Spalte 1) #$ Kommandos
je nach Kommando vorne (n*)3 Leerzeichen einfügt
oder n*3 Leerzeichen löscht
um Blockverschiebung außerhalb des Bildschirm Sichtbereiches
einfach und sicher ausführt.

--
http://www.hermann-riemann.de

Hans-Peter Jansen

unread,
Mar 1, 2022, 10:52:12 AMMar 1
to
Am Montag, 28. Februar 2022, 19:56:30 CET schrieb Stefan Ram:
> Hans-Peter Jansen <h...@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.

Taniya khan

unread,
May 12, 2022, 12:59:50 AMMay 12
to
Reply all
Reply to author
Forward
0 new messages