Dialog-Fenster öffnen.

[Hyperion]

Das ist schnell beantwortet: Jede Anwendung, die ein GUI zur Laufzeit zwingend erfordert, ist "schlecht" geschrieben.

Also dem muss man einfach widersprechen! Ein Spiel will ich eigentlich meistens mit GUI spielen, eine Desktop Umgebung will ich auch grafisch nutzen usw. Es gibt so viele Beispiele, bei denen eine GUI lose Applikation wenig sinnvoll ist, so dass die Aussage so schlicht falsch ist.

Es geht schlicht um die Trennung von Logik und GUI *im* Code. Damit wird ja gerade ermöglicht, lauffähige Programme mit allen möglichen Bedien-Facetten zu entwickeln. Ob man das in allen Fällen braucht, spielt eigentlich keine Rolle. Aber die Argumente dazu hatten wir dazu ja schon zur Genüge.

[Hellstorm]

@Hellstorm: Dafür kann man in der Konsole häufiger gebrauchte Programme, nach dem man die richtigen Optionen zusammengestellt hat, ganz einfach aus der History wiederholen und erneut ausführen oder vorher die Werte anpassen. Das ist dann bei häufiger gebrauchten Sachen deutlich schneller als wenn man erst eine GUI startet und da jedes mal aufs Neue die Datenfelder ausfüllt. Und man kann die verschiedensten Werkzeuge kombinieren und automatisieren. Was bei GUI-Anwendungen schlechter bis unmöglich ist. Benutzerfreundlich kommt anscheinend auch auf den Benutzer an.

Naja, die meisten Linux-Benutzer loben ja oft die Kommandozeile, wie gut sie denn ist und dass man damit so schnell arbeiten kann usw. Das stimmt auch für eine Gruppe Nutzer, für eine andere Gruppe Nutzer aber nicht: Für die Gelegenheitsnutzer.

Wenn ich ein Programm nur einmal alle paar Monate benutze, dann hab ich die Benutzungsweise eines Konsolenprogrammes (es sei denn es fragt explizit nach allen Informationen nach der Ausführung) schon längst wieder vergessen. Ich muss also jedes Mal erst nachlesen, wie das Programm denn zu benutzen ist, bevor ich es überhaupt nutzen kann. Bei einer GUI starte ich dagegen einfach das Programm und schau mir einfach alle Optionen mal an.

Das ist im Grunde genau das gleiche wie bei Fremdsprachen: Aktiv ist schwieriger als Passiv. Insofern man die Sprache gelernt hat, kann man ohne Probleme einen fremdsprachigen Text lesen. So einen Text allerdings selber zu schreiben ist wieder was ganz anderes. Genau das gleiche ist bei der GUI: Die GUI gibt mir die möglichen Optionen vor und ich muss sie mir nicht merken. Wenn ich die möglichen Optionen sehe, dann fällt mir die Benutzungsweise recht schnell wieder ein.

Wenn ich z.B. mit tar etwas entpacken will... Klar bin ich schneller, wenn ich 10 Dateien mit tar -xzf blabla.tar.gz nacheinander entpacke. Aber wenn ich das nur jedes halbe Jahr mache, habe ich die kryptischen Symbole -xzf wieder vergessen.

Außerdem, und das wird oft vergessen (und meiner Meinung nach sicherlich ein Grund für das Nischendasein Linux’): Kommandozeilenprogramme sind schlecht zu übersetzen. GUI-Programme lassen sich komplett übersetzen, so dass man das Englische niemals zu Gesicht bekommt. Bei Kommandozeilenprogrammen ist das aber nicht so gut möglich: Entweder hat man kryptische Symbole, die absolut nicht zu merken sind, oder man hat lange ausgeschriebene Befehle (wie --verbose – Aber wer als normaler Nutzer weiß schon, was verbose heißt?), die eben nicht zu übersetzen sind.


Vergleicht doch mal den Schwierigkeitsgrad, ein Bild mit Imagemagick und mit Paint zu verkleinern. Paint kann ich selbst nach 2 Jahren Nichtbenutzung noch sofort bedienen, bei Imagemagick habe ich das schon nach 2 Tagen wieder vergessen. Und wenn ich jetzt für mich ein Programm schreiben möchte, das etwas vereinfacht (was meiner Meinung nach als Anfänger oft der Fall ist), dann ist meiner Meinung nach eine GUI auf jeden Fall einfacher als ein CLI.


Was ich allerdings an CLIs gut finde: Sie sind recht zeitlos. Eine GUI sieht schon nach 5 Jahren nicht mehr Weiterentwickelns schon recht veraltet aus, eine CLI kann man selbst nach 10 Jahren noch wie anfangs benutzen (Sofern sich die zugrundliegende Technologie nicht ändert)

[Madmartigan]

Das ist schnell beantwortet: Jede Anwendung, die ein GUI zur Laufzeit zwingend erfordert, ist "schlecht" geschrieben.

Also dem muss man einfach widersprechen! Ein Spiel will ich eigentlich meistens mit GUI spielen, eine Desktop Umgebung will ich auch grafisch nutzen usw. Es gibt so viele Beispiele, bei denen eine GUI lose Applikation wenig sinnvoll ist, so dass die Aussage so schlicht falsch ist.

Es geht schlicht um die Trennung von Logik und GUI *im* Code. Damit wird ja gerade ermöglicht, lauffähige Programme mit allen möglichen Bedien-Facetten zu entwickeln. Ob man das in allen Fällen braucht, spielt eigentlich keine Rolle. Aber die Argumente dazu hatten wir dazu ja schon zur Genüge.

Du kannst dem gern widersprechen, das ändert aber nichts an der Aussage. Und Aussagen haben keinen Wahrheitsgehalt, daher ist die Behauptung sie wäre schlicht falsch, schlicht nicht zu beweisen.
Ich unterstelle mal du hast mich missverstanden. Ich sprach davon, dass wenn ein GUI zwingend erforderlich ist, sei der Code "schlecht". Nicht wenn es der Einsatzzweck erfordert!
Selbstverständlich liefert man z.B. Photoshop nicht ohne GUI aus, das macht keinen Sinn. Auch ein Spiel braucht ein GUI, soweit sind wir uns einig. Was macht aber der GameServer? Braucht der ein GUI? Nein! Also muss der ganze Code prinzipiell ohne GUI funktionieren und automatisiert testbar(!) sein.

Ein weiteres gutes Beispiel: Du schreibst einen einfachen Texteditor und ignorierst die Trennung von GUI und Logik. Wie schaffst du es jetzt, ohne GUI und die Notwendigkeit menschlicher Interaktion einen Batch-Process über mehrere Textdateien laufen zu lassen? Also z.B. nachträglich bei 1000 Dateien "Hallo Welt" anzufügen?

Ich denke das macht es deutlich. Wer immer noch meint, ein GUI (Graphical User Interface) sei notwendig, damit der Code benutzbar ist, ... nuja ... Rebellen gab es schon immer.

[Sophus]

So Leute, ich habe mich mal ein wenig rangesetzt. Das Thema ist immer noch das Alte.

Ich habe mit QT Designer zwei Formen erstellt, einmal hauptdialog und einmal dialog2. Beide Formen wurden entsprechend von der ui-Datei in die py-Datei umgewandelt.

Auf der Form "hauptdialog sind drei Buttons, mit folgender Beschriftung einmal "Abbrechen", einmal "Ok" und einmal "Neues Fenster".

Damit ich nicht direkt in hauptdialog.py schreibe, habe ich mit IDLE eine Datei namens programm.py angelegt.

Dort steht nun folgendes:

Code: Alles auswählen

import sys 
from PyQt4 import QtGui, QtCore 
from hauptdialog import Ui_Hauptdialog as Dlg

class MeinDialog(QtGui.QDialog, Dlg): 
    def __init__(self): 
        QtGui.QDialog.__init__(self) 
        self.setupUi(self)

        # Slots einrichten 
        self.connect(self.buttonOK, 
                QtCore.SIGNAL("clicked()"), self.onOK) 
        self.connect(self.buttonAbbrechen, 
                QtCore.SIGNAL("clicked()"), self.onAbbrechen)
        self.connect(self.Neu, 
                QtCore.SIGNAL("clicked()"), self.onNeu)

    def onOK(self): 
        # Daten auslesen 
        d = {} 
        print "Vorname: %s" % self.vorname.text() 
        print "Nachname: %s" % self.nachname.text() 
        print "Adresse: %s" % self.adresse.toPlainText() 
        datum = self.geburtsdatum.date().toString("dd.MM.yyyy") 
        print "Geburtsdatum: %s" % datum

        if self.agb.checkState(): 
            print "AGBs akzeptiert. Das finde ich wirklich super :-)" 
        if self.newsletter.checkState(): 
            print "Katalog bestellt" 
        self.close()

    def onAbbrechen(self): 
        print "Schade" 
        self.close()

    def onNeu(self):
        diaolog2.show

app = QtGui.QApplication(sys.argv) 
dialog = MeinDialog() 
dialog.show() 
sys.exit(app.exec_())

Drücke ich danach F5 funktionieren beide Buttons, also Ok und Abbrechen. Das sehen ich an den print-Ausgaben. Aber beim Klick auf "Neues Fenster" will er einfach nichts machen. Stattdessen bekomme ich bei der Python Shell folgende Meldung

"Traceback (most recent call last):
File "C:\Python27\programm.py", line 38, in onNeu
diaolog2.show
NameError: global name 'diaolog2' is not defined"

Kann mir jemand weiterhelfen?

Danke
Sophus

[Madmartigan]

1.

Code: Alles auswählen

diaolog2.show

... du meinst vielleicht

Code: Alles auswählen

dialog2.show()

Du hast da demnach einen Tippfehler und show() ist eine Funktion, also musst du da Klammern setzen (Python Basics).

2. Wo ist denn dialog2 deklariert? Leider nirgends, weder als Klasseninstanzvariable noch als lokale Variable in deiner Funktion onNeu(). Lies doch einfach mal die Fehlermeldung in Ruhe durch. Da steht doch exakt beschrieben, dass das Objekt diaolog2 nicht bekannt ist.

[Sophus]

Und wie deklariere ich das neue Fenster Dialog2? Vorschlag?

[BlackJack]

@Sophus: In dem Du die generierte Klasse importierst, eine Klasse davon ableitest, und davon dann ein Exemplar erstellst‽ Also genau das gleiche was Du schon mit dem anderen Fenster gemacht hast.

[Madmartigan]

Und wie deklariere ich das neue Fenster Dialog2? Vorschlag?

Ich verstehe nicht, wie du auf diese Frage kommst ... oder doch, wenn ich mir die vergangenen Einträge hier so durchlese, fällt es mir wieder ein.

Du scheinst die Grundlagen über OOP und parent->child Beziehungen immer noch nicht verinnerlicht zu haben. Daher wieder der gleiche Tipp, fange mit den Basics an, nimm dir ein Buch oder schau dir die zahlreichen Tutorials im Web an. Wirklich, es macht keinen Sinn weiterzumachen. wenn du das nicht verstanden hast.

Aber da heute Herrentag ist, ein Tipp:
Was musste denn geschehen, damit das objekt dialog bekannt ist? Musst das vielleicht irgendwo deklariert werden? Müsstest du also eventuell etwas Ähnliches mit dialog2 machen?

[Sophus]

Leute, eines vor weg: Diese Tipps, von wegen "lest erstmal ein Buch" ist grundlegend nervig, auch wenn es gut gemeint ist. Ein jeder Mensch lernt anders, und da gibt es keinen einheitlichen Weg von wegen "Lest erstmal ein Buch". Ich lerne lieber dadurch, dass ich nebenbei gleich "rumspiele" und dadurch entdecke, anstatt mich mich mit dicken staubtrocken Büchern rumschlage. Das ist eben meine Art zu arbeiten. Und das ich es ähnlich wie zuvor deklarieren muss ist mir auch schon klar - soweit bin ich. Nur grübel ich die Ganze Zeit an welcher Stelle ich genau ansetzen soll. Wenn es also ein Forum ist, wo man "Hilfe" bekommt, dann erwarte ich keine Verweise auf Bücher.

[Sophus]

Und für diejenigen, die mal sehen, dass ich schon soweit gedacht habe:

Code: Alles auswählen

import sys 
from PyQt4 import QtGui, QtCore 
from hauptdialog import Ui_Hauptdialog as Dlg
from dialog2 import Ui_Dialog2 as Dlg

class MeinDialog(QtGui.QDialog, Dlg): 
    def __init__(self): 
        QtGui.QDialog.__init__(self) 
        self.setupUi(self)

class MeinNeuDialog(QtGui.QDialog, Dlg): 
    def __init__(self): 
        QtGui.QDialog.__init__(self) 
        self.setupUi(self)
                
        # Slots einrichten 
        self.connect(self.buttonOK, 
                QtCore.SIGNAL("clicked()"), self.onOK) 
        self.connect(self.buttonAbbrechen, 
                QtCore.SIGNAL("clicked()"), self.onAbbrechen)
        self.connect(self.Neu, 
                QtCore.SIGNAL("clicked()"), self.onNeu)

    def onOK(self): 
        # Daten auslesen 
        d = {} 
        print "Vorname: %s" % self.vorname.text() 
        print "Nachname: %s" % self.nachname.text() 
        print "Adresse: %s" % self.adresse.toPlainText() 
        datum = self.geburtsdatum.date().toString("dd.MM.yyyy") 
        print "Geburtsdatum: %s" % datum

        if self.agb.checkState(): 
            print "AGBs akzeptiert. Das finde ich wirklich super :-)" 
        if self.newsletter.checkState(): 
            print "Katalog bestellt" 
        self.close()

    def onAbbrechen(self): 
        print "Schade" 
        self.close()
    
    def onNeu(self):
        diaolog2.show()

app = QtGui.QApplication(sys.argv) 
dialog = MeinDialog()
dialog.show() 
dialogneu = MeinNeuDialog
dialogneu.show()
sys.exit(app.exec_())

Aber offenbar will es nicht funktionieren.

[BlackJack]

@Sophus: Okay, *lies* kein Buch, sondern *arbeite es durch*. Probiere die Beispiele aus, nimm Änderungen vor, überlege Dir vor der Veränderung wie sich das auswirkt, prüfe hinterher nach ob Deine Annahme richtig war. So lernt man. Und das ist notwendig. Dir fehlt eine Menge Wissen was man nicht mal eben so nebenbei durch anschauen von fertigen Lösungen lernt, sondern das man sich selbst erarbeiten muss.

Erkläre doch mal was die beiden ``class``-Anweisungen machen. Von welchen Klassen leitest Du da jeweils ab und warum. Das Problem mit dem Quelltext an der Stelle ist eigentlich *sehr* offensichtlich.

[Sophus]

Nun, die beiden Klassen dienen womöglich dazu, dass man Instanzen erstellt. In der ersten Klasse "MeinDialog" ruft also das Fenster "hauptdialog.py". Nun liegt auf dem hauptdialog.py (welche ich per Qt-Designer schon vorher festgelegt habe) ein dritter Button. Mit dem Klick dort rauf muss quasi dialog2.py einer neuen Instanz zugeordnet werden. Auch wurde hauptdialog und dialog2 weit vorher eingebunden / importiert.

Zu deiner Annahme, BlackJack, es ist richtig. Zumal (bitte um Verlaub) handelt es sich hierbei um wirklich einfache Angelegenheiten. Ich will im Grunde erstmal nur lernen, wie ich weitere Dialoge öffnen kann und nicht wie die anderen darauf pochen OOP zu lernen.

[Madmartigan]

Und für diejenigen, die mal sehen, dass ich schon soweit gedacht habe:

Code: Alles auswählen

from hauptdialog import Ui_Hauptdialog as Dlg
from dialog2 import Ui_Dialog2 as Dlg

Aber offenbar will es nicht funktionieren.

Selbstverständlich will das nicht funktionieren. Du importierst zwei verschiedene Klassen und vergibst für beide den selben Alias dlg. Soll Python sich das nun aussuchen oder in die Glaskugel schauen?
Das mit dem "lies mal ein Buch" ist kein nerviger Tipp, sondern der dezente Hinweis, dass dieses Code-Kauderwelsch das Result deines blinden Eifers ist. Umso mehr solltest du endlich(!) einsehen, dass du die Grundlagen nicht beherrschst, also fang doch bitte erst mal damit an. "Herumprobieren" ist sicher eine Methode, aber das ist "In-die-Luft-starren" auch. Nur fragt sich ob beide in den Bereich der Programmierung gehören.

...Ich will im Grunde erstmal nur lernen, wie ich weitere Dialoge öffnen kann und nicht wie die anderen darauf pochen OOP zu lernen.

Und genau das ist der verkehrte Weg, aber das willst du leider nicht einsehen. Warum auch immer!?


Und wenn man wiederholt lesen muss, dass die angebotene Hilfe nicht willkommen ist, ferner noch mit motzigem Verhalten abgetan wird, dann wirst du bald keine Antworten mehr erhalten. Sei nur als Hinweis gedacht...

[Sophus]

Gut, Alias ist geändert. Weiter?

Warum ich nicht einsehen will, mich erstmal mit OOP auseinanderzusetzen? Ganz einfach, weil ich bereits in Visual Basic 6 ein Programm geschrieben habe und ich eine genaue Vorstellung von dem habe, wie es grafisch auszusehen hat. Also entwerfe ich erstmal die Oberfläche. Wer nund wie anfängt, ob erst OOP und dann GUI oder andersrum, dass sollte nun keine Vorschrift sein? Und das ich motzig reagiere liegt in der psychologischen Tiefe. Ich will vorwärts kommen und zwar auf meine Art und Weise. Wenn ich also wissen will, wie ich mittels eines Klicks auf dem Button ein weiteres Fenster öffnen kann, dann will ich nicht davon lesen, dass mir die OOP fehlt. Ich als zukünftiger Lehrer kann dir sagen, dass du didaktisch gesehen auf dem Holzweg bist. Und wenn ich das Gefühl habe, dass du mich eher abwimmeln willst oder mich mit meinem Vorhaben beiseite schieben willst und nur (für mich) halbe Antworten gibst, wird man eben grantig.

Stell dir doch mal vor, jemand will Autofahren lernen, und du kommst erstmal um die Ecke und erzählst ihm, dass er doch erstmal den Motor (analog zu OOP) anschauen und sich damit auseinandersetzen soll, ehe er sich reinsetzt und losfahren will. Mich interessiert der Motor momentan nicht und die Theorie genauso wenig, ich will erstmal Auto fahren und den Umgang mit der Kupplung lernen.

[BlackJack]

@Sophus: Du musst OOP können um überhaupt irgendwelche Dialoge zu öffnen. Wir pochen da ja nicht zum Spass drauf herum, sondern weil OOP eine notwendige Voraussetzung ist um mit Qt, einem objektorientierten GUI-Toolkit, *irgend etwas* zu machen. Sonst verstehst Du nicht was Du da machst, und das wäre dann kein Programmieren, sondern raten und hoffen das es irgendwie schon funktionieren wird.

Solltest Du kein Interesse daran haben obektorientierte Programmierung zu lernen, dann ist Python nichts für Dich. Insbesondere GUI-Programmierung, denn wo man bei anderen Aufgaben manchmal noch mit dem reinen prozeduralen benutzen von Objekten und Datentypen klar kommen kann die andere geschrieben haben, muss man bei GUIs selber Datentypen, also Klassen, entwerfen und schreiben können, und das auch wirklich verstanden haben. Und zusätzlich zur ganz allgemeinen OOP auch konkret die Entwurfsmuster die in Qt verwendet werden.

[Sophus]

Nun dachte ich mir, erstelle ich zwei Klassen extra:

Code: Alles auswählen

import sys 
from PyQt4 import QtGui, QtCore 
from hauptdialog import Ui_Hauptdialog as Dlg
from dialog2 import Ui_Dialog2 as Dlg1

class MeinDialog(QtGui.QDialog, Dlg): 
    def __init__(self): 
        QtGui.QDialog.__init__(self) 
        self.setupUi(self)
                
        # Slots einrichten 
        self.connect(self.buttonOK, 
                QtCore.SIGNAL("clicked()"), self.onOK) 
        self.connect(self.buttonAbbrechen, 
                QtCore.SIGNAL("clicked()"), self.onAbbrechen)

    def onOK(self): 
        # Daten auslesen 
        d = {} 
        print "Vorname: %s" % self.vorname.text() 
        print "Nachname: %s" % self.nachname.text() 
        print "Adresse: %s" % self.adresse.toPlainText() 
        datum = self.geburtsdatum.date().toString("dd.MM.yyyy") 
        print "Geburtsdatum: %s" % datum

        if self.agb.checkState(): 
            print "AGBs akzeptiert." 
        if self.newsletter.checkState(): 
            print "Katalog bestellt" 
        self.close()

    def onAbbrechen(self): 
        print "Schade" 
        self.close()

app = QtGui.QApplication(sys.argv) 
dialog = MeinDialog()
dialog.show() 
sys.exit(app.exec_())

class MeinNeuDialog(QtGui.QDialog, Dlg1): 
    def __init__(self): 
        QtGui.QDialog.__init__(self) 
        self.setupUi(self)
        
        # Slots einrichten 
        self.connect(self.Neu, 
                QtCore.SIGNAL("clicked()"), self.onNeu)
    
    def onNeu(self):
        diaolog2.show()
                
app = QtGui.QApplication(sys.argv) 
dialogneu = MeinNeuDialog
dialogneu.show()
sys.exit(app.exec_())

Also in der ersten Klasse klappt alles. Die Prints werden ausgegeben, aber noch immer wird kein zweites Fenster geöffnet -.-

[Madmartigan]

[...]
Und das ich motzig reagiere liegt in der psychologischen Tiefe. Ich will vorwärts kommen und zwar auf meine Art und Weise. Wenn ich also wissen will, wie ich mittels eines Klicks auf dem Button ein weiteres Fenster öffnen kann, dann will ich nicht davon lesen, dass mir die OOP fehlt. Ich als zukünftiger Lehrer kann dir sagen, dass du didaktisch gesehen auf dem Holzweg bist. Und wenn ich das Gefühl habe, dass du mich eher abwimmeln willst oder mich mit meinem Vorhaben beiseite schieben willst und nur (für mich) halbe Antworten gibst, wird man eben grantig.

Also darauf will mir fast nichts einfallen...

Du willst also Lehrer sein oder werden!? ... Nun dann solltest du vielleicht in Erwägung ziehen, hier etwas mehr Sinn und Verstand zu zeigen. Dein Habitus zeugt aber von einer solch ignoranten Beratungsresistenz, dass ich schon jetzt um das Wohl deiner dir künftig anvertrauten Schüler besorgt sein möchte. "Auf dem Holzweg" beschreibt wirklich einzig und allein deine Vorgehensweise, meine Didaktik muss dich nicht kümmern.

Ich frage mich, womit ich den Eindruck erweckt haben könnte, ich wolle dich abwimmeln oder beiseite schieben. Noch selten hat jemand dieses Maß an Aufmerksamkeit, Hinweisen und absolut positiv gemeinten Ratschlägen bekommen. Aber gut, das war es dann von meiner Seite, vielleicht sind andere noch mit Motivation und Geduld gesegnet und spielen dieses Theater weiter.

Guten Abend.

[BlackJack]

@Sophus: „Ach lass mich doch mit der Strassenverkehrsordnung in Ruhe, und auch das mit dem Zündschloss und mit diesen Pedalen da unten will ich jetzt gar nicht wissen, ich will nur *autofahren*”. Das ist eher der Vergleich.

Wurde schon erwähnt das Dir absolute Grundlagen fehlen, und das ”raten” von Quelltext nichts bringt ausser höchstens Zufallserfolge‽ Schau mal in die Dokumentation was `sys.exit()` macht.

[Sophus]

*seufz*

Gibt es denn ein gescheites gutes Buch, was ihr mir empfehlen würdet? Und bitte keine "Hello World"-Gespiele.

[Madmartigan]

Es gibt jede Menge Bücher, eine Suche im Netz liefert dir zahllose Beispiele. Wenn du kein Buch nutzen magst, dann hättest du längst nach Tutorials o.Ä. suchen können.

http://zetcode.com/gui/pyqt4/
http://zetcode.com/gui/pysidetutorial/
http://zetcode.com/lang/python/
http://zetcode.com/lang/python/oop/

Nur einige wenige Beispiele. Die sind allerdings in englischer Sprache, aber als angehender Pädagoge ist das sicher kein Problem für dich.