Dialog-Fenster öffnen.

Python und das Qt-Toolkit, erstellen von GUIs mittels des Qt-Designers.
Benutzeravatar
Sophus
User
Beiträge: 1109
Registriert: Freitag 25. April 2014, 12:46
Wohnort: Osnabrück

Hallo Leute,

eines vorweg: Ich bin ein absoluter Anfänger. Ich habe mir gestern erst aus reiner Neugier Python-xy installiert. Dazu nutze ich auch die IDE Eclipse. Ich habe es sogar geschafft Eclipse so einzustellen, dass es für Python eingerichtet ist. Ihr seht also, ich bin ein sehr sehr sehr frischer Anfänger. Von daher bitte nicht zu hoch greifen, und wenn es unumgänglich ist, dann bitte mit ausführlichen Ausführungen zum Programmcode, sonst habe ich das Gefühl ihr schreibt die ganze Zeit Chinesisch und ich armes Würstchen verstehe euch nicht :-)

Nun, ich habe mir mit Hilfe von Qt-Designer mehrere Formulare angelegt. Dort sind Labels, Textboxen und Buttons drauf. Wie kriege ich es nun hin, dass ich mit Hilfe eines Klcikes auf den Buttons eine weitere Form bzw. ein weiteres Dialog-Fenster öffnen kann?

Vielen Dank schon mal für eure Hilfe.
BlackJack

@Sophus: So von gestern auf GUI ist vielleicht ein wenig schnell. Bevor man mit GUI-Programmierung anfängt, sollte man IMHO die Grundlagen inklusive objektorientierter Programmierung (OOP) drauf haben. Mit GUIs kommen da nämlich noch ereignisorientierte Programmierung, ein umfangreiches Rahmenwerk, und OOP-Entwurfsmuster hinzu. Das alles zusammen ist ein wenig viel auf einmal.
Benutzeravatar
Sophus
User
Beiträge: 1109
Registriert: Freitag 25. April 2014, 12:46
Wohnort: Osnabrück

Echt? Also ich programmiere nebenbei in VB6. Dort ist das Aufrufen einer Form bzw. Dialogfensters das einfachste was es gibt. Zum beispiel ruft man folgende Form wie folgt auf:

Form1.Show

Hier ist Form1 der Name der Form. Und ich dachte das wäre hierbei so ähnlich :-)
Malta
User
Beiträge: 83
Registriert: Samstag 8. Januar 2011, 23:51

In der def __init__(self):

Code: Alles auswählen

self.ui.btn_draw_overview.clicked.connect(self.onbtn_draw_overview)
self.ui.action_info.triggered.connect(self.oninfo)
Einen Dialog:

Code: Alles auswählen

    def onbtn_draw_overview(self):
        """show dialog of the draw"""
        dlgdraw = DlgShowDrawing(self.random_number, self.highest)
        dlgdraw.exec_()

Eine MessageBox:

Code: Alles auswählen

    def oninfo(self):
        a = QtWidgets.QMessageBox()
        a.setWindowTitle('Info')
        a.setText('text')
        a.setInformativeText('InformativeText')
        a.exec_()
Die Beispiel habe ich aus meinem Lottoprogramm
https://github.com/MarkusHackspacher/pyLottoSimu/
Vielleicht wird es im ganzen Quelltext besser ersichtlich.
Benutzeravatar
Madmartigan
User
Beiträge: 200
Registriert: Donnerstag 18. Juli 2013, 07:59
Wohnort: Berlin

Sophus hat geschrieben:Echt? Also ich programmiere nebenbei in VB6. Dort ist das Aufrufen einer Form bzw. Dialogfensters das einfachste was es gibt. Zum beispiel ruft man folgende Form wie folgt auf:

Form1.Show

Hier ist Form1 der Name der Form. Und ich dachte das wäre hierbei so ähnlich :-)
Würdest du auch sagen, ein im Meer treibender Eisberg sei kein Hindernis, weil der sichtbare respektive für dich wahrnehmbare Teil so klein ist? :roll:

Die Metapher soll dir nur klar machen, dass es absolute nicht das "Einfachste" ist, ein Dialogfenster anzuzeigen. Was nicht existiert, kann nicht sichtbar gemacht werden. Also muss das Dialogfenster erst erstellt werden, Eigenschaften gesetzt werden usw usw.

Form1.Show impliziert, dass es dieses Objekt bereits gibt. Wer hat das denn erstellt? Objekte tauchen nicht von alleine auf. Das nimmt dir der visuelle GUI Designer bereits ab, daher haben Anfänger meist leider keinerlei Ahnung von den elementaren Dingen. Den mächtigen Frameworks und IDEs sei es angelastet.

Nimm die Hinweise von BlackJack bitte ernst, sonst hast du auf Dauer keine Freude. Um mit Python und Qt zu arbeiten, braucht es keine IDE oder GUI Designer, man kann in einem "einfachen" Editor (Emacs, Vim, Notepad++) Code schreiben und das Ganze aus der Python Console starten. Wenn man die Grundlagen der OOP beherrscht, guten Non-UI Python Code schreibt und eine Idee hat, was die großen IDEs und GUI Designer eigentlich unter der Haube machen, dann wird GUI-Programmierung wesentlich leichter.
Benutzeravatar
Sophus
User
Beiträge: 1109
Registriert: Freitag 25. April 2014, 12:46
Wohnort: Osnabrück

Ich glaube mein erster Eintrag wurde nicht gründlich gelesen. Ich schrieb, dass ich bereits zwei Dialoge unter Ot-Designer angelegt habe. Auf jedem Dialog befindet sich schlicht und einfach eine LineEdit, PushButtion und ein Label. Damit ich die beiden Dialoge auch voneinander unterscheiden kann, bekam das eine Fenster den Namen Fenster1 und das andere Fenster den Namen Fenster2. Nun existieren diese beiden Objekte ja schon und müssen nicht her aus den nichts erzeugt werden. Und nun war meine Idee, mit einem Klick auf den PushButton des ersten Fenster soll das zweite Fenster sichtbar gemacht werden. Mehr wollte ich nicht. Keine Funktion etc.
BlackJack

@Sophus: Nein, die Objekte existieren noch nicht. Mit dem Qt-Designer entwirft man nur die Oberfläche als Datendatei. Die kann man dann zur Laufzeit laden, oder sich Code für entsprechende Klassen erstellen, die man dann in seinen eigenen Code einbinden kann. Ohne selber Code zu schreiben, und zwar bei allem was nicht supertriviales „Hello world” ist, objektorientierten Code, also Klassen und Methoden, bekommt man da nichts angezeigt.

Und dazu wäre es halt praktisch wenn man OOP kann bevor man sich mit GUIs beschäftigt. Weil beides gleichzeitig zu lernen, schwerer ist, als erst einmal die Grundlagen zu lernen.

Edit: Wenn beide Fenster tatsächlich gleich aufgebaut sind, und nur aus den genannten Bestandteilen bestehen, dann wäre es sowieso günstiger eine Klasse von Hand zu schreiben wo man die Beschriftung des Label und der Schaltfläche als Argumente beim erstellen übergibt. Dann kann man beliebig viele Exemplare davon erstellen, mit beliebigen Beschriftungen. Für so etwas einfaches bemüht man normalerweise keinen GUI-Designer.
Benutzeravatar
Sophus
User
Beiträge: 1109
Registriert: Freitag 25. April 2014, 12:46
Wohnort: Osnabrück

Ich sehe schon, da kommt noch einiges auf mich zu. Und dann das noch alleine :-) VB6 habe ich damals vor Jahren in der Ausbildung zum Informatikkaufmann gelernt, und da hatte man seinen Ausbilder dabei der einem über die Schulter guckte und unterstützte. Und jetzt habe ich schon bammel, dass ich Python nicht auf die Reihe kriege :-D Meine Grundidee ist, ich habe in VB6 ein recht großes Projekt geschrieben, es handelt sich hierbei um eine Datenbank-Anwendung. In meinem Projekt arbeite ich mit Microsoft Access. Nun dachte ich, sattel ich mich um auf Python, und da kann ich dann auch gleichzeitig mein Programm dann auch in Linux verwenden :-) Puuuh :-)
Benutzeravatar
Madmartigan
User
Beiträge: 200
Registriert: Donnerstag 18. Juli 2013, 07:59
Wohnort: Berlin

Sophus hat geschrieben:Ich glaube mein erster Eintrag wurde nicht gründlich gelesen.
Oh Gott, das stand nirgends. Ich wusste nicht, dass ich Beiträge gründlich lesen muss, bevor ich antworte! :twisted:
Keine Sorge, das war mitnichten oberflächlich, sondern als hilfreicher Hinweis gedacht.

Es ist irrelevant auf welche Sprache du umsatteln willst, die Prinzipien greifen immer. Erst sollte man die Grundlagen beherrschen, dann an grafische Oberflächen denken. Deine Anwendung nach Python zu portieren funktioniert auch erst mal komplett ohne GUI. Wenn das dann getestet ist und läuft, kannst du ohne Probleme ein GUI anbinden.
Benutzeravatar
Sophus
User
Beiträge: 1109
Registriert: Freitag 25. April 2014, 12:46
Wohnort: Osnabrück

Nicht zwangsläufig. Zum Beispiel bei VB6 lernst du beides. Die Programmiersprache ist so konzipiert, dass sie ausschließlich an die Oberfläche gebunden ist - Microsoft eben :-) Denn Microsoft schickt in eine VB6 die komplette IDE mit, damit man ohne Probleme eine Oberfläche gestalten kann und soll. Daher bin ich auch an diesem Prinzip gewohnt.
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

Um noch einmal auf das leider leidige Thema VB (oder auch gerne Delphi oder ähnlich aufgemachte Vermengungen aus Sprache,IDE und Framework) zurück zu kommen: Wer Programmieren mit GUIs erlernt, der lernt meistens auch direkt, die GUI und die Logik zu vermischen! Dabei heraus kommt dann unwartbarer und zumeist auch untestbarer Code :-(

Das schlimmste daran ist jedoch, dass man diese Dinge später mühsam Stück für Stück "entlernen" muss, da man ansonsten auf der Stelle tritt und sich niemals sinnvoll weiterentwickelt.

Letztlich leidet PHP fast noch viel stärker an diesem Dilemma: Ohne visuelles Feedback kann man die Sprache kaum erlernen - genau da liegt imho der Vorteil von Python (und anderen Sprachen), die *nicht* durch einen Vermarkter oder eine tumbe Community dermaßen als Einheit dargestellt werden.

Ich bin mir sicher, dass man Delphi auch komplett GUI frei schreiben kann; aber wer macht das schon und bekommt man das in gängigen Büchern und Tutorials auch vermittelt?

Und weil der Beitrag während meines Tippens frisch reinkam:
Sophus hat geschrieben: enn Microsoft schickt in eine VB6 die komplette IDE mit, damit man ohne Probleme eine Oberfläche gestalten kann und soll. Daher bin ich auch an diesem Prinzip gewohnt.
q.e.d. :twisted:

Ist Dir bewusst, *dass* man Logik und GUI trennen sollte? Und wenn ja, weißt Du auch *wie* man das bewerkstelligen kann? Und hast Du das in VB auch so praktiziert? Ich denke mal "nein", oder? ;-)
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
Benutzeravatar
Sophus
User
Beiträge: 1109
Registriert: Freitag 25. April 2014, 12:46
Wohnort: Osnabrück

Ich erkenne nicht worauf du hinaus möchtest. Was ist daran so verkehrt, wenn man in VB6 gleichzeitig an der Oberfläche arbeitet, und dann mit einem kleinen Klick zum Quellcode rüber springt? Denn auch im Quellcode muss man seine Logik verfolgen. Ich denke einfach, es ist nicht verkehrt beides miteinander stark zu vermischen. Ich bin sehr stark visuell veranlagt, und arbeite anhand der Oberfläche entlang. Ich sehe dann "Aha, hier und da sind Textboxen/LineEdit, und hier und da sind dann die Buttons, und die sollen zur Laufzeit so und so gestaltet werden, und dort platziert werden", und so hat man ein Bild vor Augen und weiß auch was man da wirklich programmiert. Ich will niemals absprechen, dass es falsch sei, dass man ohne GUI programmieren soll, aber jeder Mensch ist eben anders veranlagt. Und du meinst auch, dass man durch die Vermischung von Oberflächen-Gestaltung und Programmierung zum untestbaren Code kommt? Ich greife nochmal auf VB6 zurück. Du kannst jederzeit das Programm ohne Umstände starten. Du hast einen kleinen Abschnitt programmiert, und willst sehen wie es funktioniert, dann drückst du einfach "Abspielen" und du bekommst das Programm zur Laufzeit. Ich will nun keine Grundsatzdiskussion starten. Ich finde Python genauso interessant. Aus diesem Grund bin ich ja auch hier. Aber mir will nicht begreiflich sein, was daran "falsch" sei und wie dies unvermeidlich zum Fehler-Code kommen muss, wenn man beides lernt? In VB6 MUSS man ja beides lernen, und man muss hinterher nicht zwangsläufig Stück für Stück alles "entfernen".
BlackJack

@Sophus: Logik/Programmlogik meint hier die Logik die nichts mit der GUI zu tun hat, also der Teil der tatsächlich die gestellten Probleme löst und nicht zur Interaktion mit dem Benutzer dient. Und das sollte man nicht vermischen. Das ist keine Geschmacksfrage, wer das stark vermischen will, ist mit seiner Meinung ein krasser Aussenseiter.

Und testbar meint ohne GUI eben die Programmlogik, automatisiert und wiederholbar zu testen. Nicht das da ein Mensch mal das Programm startet und was ausprobiert.

In VB (vor .NET) lernt man nicht beides und muss das auch gar nicht, das ist ja gerade das Problem das die Leute da die Trennung nicht lernen, weil man sie nicht machen muss, und man auch nicht ermutigt wird das zu tun. Man lernt nicht dass man da zwei Dinge vermischt, lernt also auch nicht was was ist und wie man es trennt. Genau mit dem Problem wirst Du ja jetzt gerade konfrontiert.
EmaNymton
User
Beiträge: 174
Registriert: Sonntag 30. Mai 2010, 14:07

Sie es vielleicht auch mal aus der Sicht, dass du dich für immer und ewig damit auf VB6 (oder eine beliebige andere Kombination aus IDE/Sprache) festgelegt hast und dir damit die Flexibilität nimmst. Ich spreche da aus eigener Erfahrung:
Damals(TM) für mein N900 mit PyQt ein paar Programme geschrieben und als Anfänger alles schön vermischt. Dann kam das N9, wo statt PyQt nun Python/QML die notwendige Kombination war, jetzt Blackberry 10 oder Sailfish OS, die auch die Kombination Python/QML verwenden. Hätte ich damals mein Backend komplett in Python und von der Oberfläche unabhängig geschrieben, wäre mir viel Arbeit erspart geblieben, da ich diesen Code fast 1:1 hätte übernehmen können. So sind halt einige Projekte auf Eis gelegt (oder gestorben), was man hätte vermeiden können.
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

Sophus hat geschrieben:Ich erkenne nicht worauf du hinaus möchtest. Was ist daran so verkehrt, wenn man in VB6 gleichzeitig an der Oberfläche arbeitet, und dann mit einem kleinen Klick zum Quellcode rüber springt?
Nichts! An sich ist das sogar komfortabel! Und das können andere IDEs mit integriertem Designer durchaus auch.
Sophus hat geschrieben: Ich denke einfach, es ist nicht verkehrt beides miteinander stark zu vermischen.
Und hier genau irrst Du. Daran ist *alles* verkehrt :!:

Das Thema ist schon so oft so ergiebig diskutiert worden, daher nur ein paar Stichworte:
Testbarkeit, "Separation of Concern", Wiederverwendbarkeit, ...

Edit: Ok, BlackJack war schneller :-)
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
Benutzeravatar
Sophus
User
Beiträge: 1109
Registriert: Freitag 25. April 2014, 12:46
Wohnort: Osnabrück

Ich muss gestehen, dass ich an einigen Stellen Probleme habe, mich in eure Gedankenwelt hinein zu versetzen. Es gibt durchaus Bereiche in VB, wo keine Interaktion mit dem Anwender zustande kommt. Zum Beispiel Module oder Klassen. Aber auch hier stelle ich gerade fest, dass der Anwender mit den Klassen und Modulen in VB6 in Berührung kommt. Denn eine Klasse oder ein Modul ist sozusagen eine globale Instanz. Hier schreibt man bestimmte Funktionen rein, die dann auf viele Bereiche übergreifen. Zum Beispiel schreibe ich in VB6 eine Klasse, die dafür sorgt, dass bestimmte Formen beim Reize-Ereignis eine bestimmte Größe nicht überschreiten darf - zum Beispiel Form darf nicht zu groß und auch nicht zu klein sein. Hier schreibe ich also die Klasse indirekt unabhängig von der Oberfläche. Oder verstehe ich euch immer noch nicht?

BlackJack hat geschrieben:@Sophus: Logik/Programmlogik meint hier die Logik die nichts mit der GUI zu tun hat, also der Teil der tatsächlich die gestellten Probleme löst und nicht zur Interaktion mit dem Benutzer dient. Und das sollte man nicht vermischen. Das ist keine Geschmacksfrage, wer das stark vermischen will, ist mit seiner Meinung ein krasser Aussenseiter.

Und testbar meint ohne GUI eben die Programmlogik, automatisiert und wiederholbar zu testen. Nicht das da ein Mensch mal das Programm startet und was ausprobiert.

In VB (vor .NET) lernt man nicht beides und muss das auch gar nicht, das ist ja gerade das Problem das die Leute da die Trennung nicht lernen, weil man sie nicht machen muss, und man auch nicht ermutigt wird das zu tun. Man lernt nicht dass man da zwei Dinge vermischt, lernt also auch nicht was was ist und wie man es trennt. Genau mit dem Problem wirst Du ja jetzt gerade konfrontiert.
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

Bitte vermeide hier doch TOFU :-)
Sophus hat geschrieben:Hier schreibe ich also die Klasse indirekt unabhängig von der Oberfläche. Oder verstehe ich euch immer noch nicht?
Ich denke, dass Du uns noch immer nicht verstehst!

Stell Dir vor, Du willst einen BMI-Rechner bauen.

Ein Mockup sieht z.B. so aus:
Bild

Wie würdest Du jetzt vorgehen?
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
Benutzeravatar
Sophus
User
Beiträge: 1109
Registriert: Freitag 25. April 2014, 12:46
Wohnort: Osnabrück

So wie du es gemacht hast - erst würde ich mir eine grafische Oberfläche basteln, die LineEdits entsprechen beschriften, anschließend würde ich mich sachkundig machen, wie man mit der BMI-Rechnung umgeht - sprich die Formel für mich erstellen. Bestimmt ein falscher Weg?
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

Nehmen wir an, Du kennst die Formel. *Wo* würdest du diese nun "hinschreiben"?
encoding_kapiert = all(verstehen(lesen(info)) for info in (Leonidas Folien, Blog, Folien & Text inkl. Python3, utf-8 everywhere))
assert encoding_kapiert
Benutzeravatar
Sophus
User
Beiträge: 1109
Registriert: Freitag 25. April 2014, 12:46
Wohnort: Osnabrück

Nun, ich würde die erstellte Form bzw. den erstellten Dialog erstmal in die Sprache umwandeln, als in Python. Nach der Umwandlung würde ich dann diese Datei dann mit Eclipse öffnen, und dort codieren. Wo in welchem Abschnitt wüsste ich jetzt natürlich nicht :-)
Antworten