QtDesigner – Gibt es eine Anleitung für den Einstieg?

  • Das „eine Datei“-Argument ist keins. Das interessiert keinen ausser Leute, die versuchen wollen ihren Code zu verstecken. Eine Datei für den Endnutzer bekommt man auch wenn man einfach alles in eine Archivdatei steckt. Wobei ich mir auch fast sicher bin, dass man auch .ui-Dateien in Qt-Ressourcen stecken kann. Und man kann bei den üblichen Werkzeugen um ”eine” Datei aus Python-Programmen zu erzeugen auch Datendateien mit verpacken. Letztlich bekommt halt ein ZIP-Archiv mit einem kleinen EXE-Kopf, der jedes mal wenn man das Programm ausführt, alles in ein temporäres Verzeichnis entpackt, also den Python-Interpreter, die Standardbibliothek, Qt, die Python-Anbindung an Qt, andere Module von Drittanbietern, die Module des Programms selbst. Das wird alles entpackt und dann ausgeführt. Ich finde das an sich schon irre, aber unter Linux noch bekloppter, weil die ganzen Sachen ausser dem eigenen Code dort ja schon da sind, oder zumindest über die Linux-Paketverwaltung installiert werden können.


    Man hat mit den .ui-Dateien einen Arbeitsschritt weniger. Und man kann auch alles unter Versionsverwaltung stellen, ohne das man nach dem auschecken, entweder selbst, oder wenn das jemand anderes tut, noch irgendwelche Dateien generieren muss, um das Programm dann komplett zu haben. Denn generierte Dateien gehören nicht in die Versionsverwaltung.


    Generierten Code will man in der Regel auch gar nicht sehen, denn Codegeneratoren sind in der Regel nicht darauf ausgelegt was zu erzeugen was Menschen lesen sollen. Man hat bei Python ein bisschen Glück, dass die Sprache gewisse Sachen erzwingt, die das lesen einfacher machen, aber das was da aus den .ui-Dateien erzeugt wird ist kein Code an dem man sich für eigene Programme orientieren sollte. Man kann sich das ja mal generieren um rein zu schauen, aber das ist kein Grund für die Benutzung davon.

    “Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life.” — Terry Pratchett, Jingo

  • Hallo,

    erstmal zum Thema "Eine Datei". Wenn man das nur in Bezug auf den Raspberry Pi betrachtet, dann gebe ich Dir Recht. Das ist hier Blödsinn!


    Aber Python und QT gibt es ja nicht nur für den Kleinen. Da sind dann auch Rechner und Systeme dabei, bei denen Python und QT nicht installiert sind. Und da kann so eine Datei schon hilfreich sein. Und das was Du da für die UI Variante vorschlägst, sicher wenn man was erreichen will, wird man fast immer eine Lösung finden. Nur Deine Ideen dazu klingen nicht gerade sehr einfach.


    Hast Du Dir denn das Video einmal angesehen? Scheinbar nicht! Denn was bei dem Verfahren rauskommt ist ganz einfaches Python, so wie Du es auch von Hand schreiben würdest, wenn Du die Kenntnisse dazu hättest.


    Und wenn man generierten Code nicht unter die Versionsverwaltung stellen will, dann kann man diese Dateien ja auch ausschließen. Und ob man nun die Oberfläche als UI (XML) Datei oder als Python in seinem Projekt hat, das ist Ansichtssache. Mir gefällt die einheitliche Lösung einfach besser als diese fast unleserliche XML Geschichte. Und es stört mich auch etwas, wenn da im Hintergrund aus meinem Design was gemacht wird, was ich so nicht nachvollziehen kann. Bei der Python Variante habe ich da wenigstens ein bisschen die Möglichkeit was zu sehen und zu verstehen.

  • Der Vorteil des generierten Codes ist, dass eine IDE die Referenzen zu existierenden Objekten innerhalb des Widgets vorschlagen kann. Das geht auch mit VSCode. Wenn man nur die .ui-Dateien lädt, fehlen einem die Referenzen im Code. Sie sind zwar zur Laufzeit des Codes vorhanden, aber die IDE kann damit nichts anfangen.

  • @Brownbear: Grrr, jetzt habe ich das Video angesehen — was für eine verschwendete Zeit. Du gingst davon aus ich hätte es nicht gesehen — warum? Denn ich weiss nicht mehr als vorher und dementsprechend ändert sich da auch nichts an meiner Einstellung oder Argumentation gegen das generieren von Quelltext wenn man diesen Schritt auch leicht umgehen kann.


    UI-Dateien sind XML was mit Python nichts zu tun hat, wird irgendwie so gesagt als wenn das schlecht wäre. UI-Dateien haben halt auch nicht viel mit Programmcode zu tun, darum ist das überhaupt nicht schlecht, dass das kein Programmquelltext ist. Grössere Layouts will man auch gar nicht als Quelltext lesen, weil das massiv unübersichtlich ist, und ja auch der Grund warum man überhaupt den Designer verwenden will.


    Wobei die Aussage in dem Video, dass man das, was man da an generiertem Code sieht, alles zu Fuss schreiben müsste, natürlich auch nicht stimmt. Da ist viel das eigentlich unnötig ist, und in Code hat man im Gegensatz zum Designer auch die Möglichkeit *Code* zu schreiben und zu nutzen, also Funktionen/Methoden und Schleifen, damit man sich wiederholende Sachen nicht tatsächlich als Code schreiben muss. Ich habe das Beispiel aus dem Video mal im Designer nachgestellt (ordentlich mit Layouts statt mit absolten Positions- und Grössenangaben) und das ist der mit pyuic5 generierte Quelltext:

    Den Wust will doch kein Mensch wirklich lesen. Erst recht nicht wenn die GUI nicht mehr so klein und einfach aufgebaut ist.


    Von Hand geschrieben sähe das so aus *und* hat auch gleich die Reaktion auf die Auswahl eines Radiobutton mit etwas sprechender Ausgabe als einfach nur nummeriert von 1 bis 6:


    Und das ganze noch mal mit laden der .ui-Datei:


    Zurück zum Video: Importe so abzukürzen ist furchtbar und auch bei anderen Namen wird viel zu viel abgekürzt. (`wnd` für `window`, Modulname `mqt`, `mgui` für?) Aussagekräftige Namen sind ”Rotz” den man nicht immer schreiben will, und `rb1` bis `rb6` sind vertretbare Namen‽ 😱 Ja nee, nicht wirklich.


    Alles auf Modulebene und aus der generierten Klasse, die eigentlich als Mixin gedacht ist, wird ein Exemplar erstellt. Argh. Er sagt ja selbst er versteht nicht so ganz was da passiert. Dann sollte man vielleicht auch keine Erklärvideos dazu machen wo man eine falsche Verwendung zeigt. 🙄

    “Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life.” — Terry Pratchett, Jingo

  • Den Wust will doch kein Mensch wirklich lesen.

    Code
    # WARNING: Any manual changes made to this file will be lost when pyuic5 is
    # run again.  Do not edit this file unless you know what you are doing.

    Das ist auch gar nicht für Menschen bestimmt. Der generierte Python-Quellcode muss importiert werden. Dadurch kann eine IDE die Symbole auflösen. Alles, was programmatisch ablaufen soll, muss eben dort gemacht werden, wo das generierte Modul importiert wird (oder woanders hin delegieren).



    Dann sollte man vielleicht auch keine Erklärvideos dazu machen wo man eine falsche Verwendung zeigt.

    Davon gibt es ganz viele. Leider werden diese Videos dann oft als Referenzen verwendet.

  • DeaD_EyE Das man in den generierten Code reinschauen kann, wurde halt von @Brownbear als Vorteil gegenüber der .ui-Datei genannt. Da würde ich sogar sagen, dass die .ui-Datei besser zum reinschauen ist, denn in dem XML ist der Objektbaum, der zur Laufzeit aufgebaut wird, wenigstens sichtbar. Im Gegensatz zum generierten Quelltext, wo das alles ”flachgeklopft” linear drin steht. Mit einem XML-Editor oder entsprechender Unterstützung in einem Texteditor (outline, folding, …) ist die XML gar nicht so kryptisch wie man vielleicht auf den ersten Blick vermuten könnte.

    “Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life.” — Terry Pratchett, Jingo