Dialog-Fenster öffnen.

[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.

[Hyperion]

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.

Hu? Natürlich haben Aussagen einen Wahrheitsgehalt - das Wort Aussagenlogik beinhaltet das sogar!

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!

Hä? Wenn eine GUI erforderlich ist, ist der Code also schlecht. Wenn es der Einsatzzweck erfordert, ist es natürlich ok‽ Sorry, das kapiert ja kein Mensch mehr, denn da widersprichst Du Dir ja selber und mit letzterem Teil stimmst Du mir ja zu!

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.

Na also, genau das sagte ich doch! Natürlich gibt es Tools, die zur Laufzeit *zwingend* eine GUI voraussetzen; das bedeutet ja nicht, dass diese nicht sehr gut testbar geschrieben sind!

Was macht aber der GameServer? Braucht der ein GUI? Nein! Also muss der ganze Code prinzipiell ohne GUI funktionieren und automatisiert testbar(!) sein.

Äh... nö. Ein Server hat idR auch externe Abhängigkeiten, die eben *nicht* per Unit Test testbar sind, z.B. sämtliche Netzwerkkommunikation. Auch bei dieser muss man irgend wie faken - genau wie bei einer GUI-Komponente Nur sehe ich den Widerspruch zu mir nicht... natürlich gibt es jede Menge an Programmen, der keine GUI hat und auch keine zur Laufzeit benötigt. Darum ging es doch gar nicht!

Ich denke Du hast da zu vorschnell eine These raus gehauen, die so einfach nicht stimmt.

[Madmartigan]

Oh wow, du mühst dich hier wirklich ab und kommentierst alte Beiträge. Da muss dir ja etwas gewaltig auf den Magen geschlagen haben, dass meine Sätze deine Aufmerksamkeit derart in Anspruch nehmen.

Hä? Wenn eine GUI erforderlich ist, ist der Code also schlecht. Wenn es der Einsatzzweck erfordert, ist es natürlich ok‽ Sorry, das kapiert ja kein Mensch mehr, denn da widersprichst Du Dir ja selber und mit letzterem Teil stimmst Du mir ja zu!

Du hast die Begründung nicht verstanden. Es ging darum, ob ein GUI notwendig sei, damit ein zugrunde liegender Code funktionieren darf. Meine Antwort ist doch diesbezüglich eindeutig. Der Code muss ohne GUI lauffähig sein, hier fragt man nicht nach sinnvoller Einsetzbarkeit im Sinne des menschlichen Nutzers. Selbstverständlich benötigt Letzterer oft eine passende Schnittstelle zur Verwendung des Codes, daher ja Interface. Wenn das nicht klar ist, dann empfehle ich eindringliche Literatur, Jef Raskin wäre ein Anfang.

Natürlich gibt es Tools, die zur Laufzeit *zwingend* eine GUI voraussetzen; das bedeutet ja nicht, dass diese nicht sehr gut testbar geschrieben sind!

Voraussetzen - nur weil der Mensch das Tool verwendet. Ich bin im sechsten Jahr Tool- und Engine-Entwickler - rein zum Funktionieren braucht meiner Erfahrung nach kein einziges Tool ein GUI. Tests auf Fehler und Funktionalität funktionieren ohne GUI, mit GUI sind die Tests nicht automatisierbar und benötigen menschliche Interaktion (Usability-Tests).

Automatisiert zu testen beschränkt sich nicht auf Unittests. Wenn das deine Annahme war, spare ich mir mal den Kommentar zu dem Satz. Fakes gehören ja wohl auch eher in den Bereich Sales, Producing und Marketing....

[Hyperion]

Oh wow, du mühst dich hier wirklich ab und kommentierst alte Beiträge. Da muss dir ja etwas gewaltig auf den Magen geschlagen haben, dass meine Sätze deine Aufmerksamkeit derart in Anspruch nehmen.

Ja, insbesondere wenn der Kommentar einen überheblichen Tonfall hat und dazu noch inhaltlich falsch ist

(Ich erinnere mich gerne an so einen Typen aus dem "Perfekten Dinner": "Ich habe schon besseres Terrakotta gegessen ..." )

Du hast die Begründung nicht verstanden. Es ging darum, ob ein GUI notwendig sei, damit ein zugrunde liegender Code funktionieren darf. Meine Antwort ist doch diesbezüglich eindeutig. Der Code muss ohne GUI lauffähig sein, hier fragt man nicht nach sinnvoller Einsetzbarkeit im Sinne des menschlichen Nutzers.

Nein! Du schriebst:

Jede Anwendung, die ein GUI zur Laufzeit zwingend erfordert, ist "schlecht" geschrieben.

Da steht etwas von Anwendung - das ist doch eine ganz andere Ebene! Natürlich besitzt eine Anwendung idR. eine Menge GUI unabhängigen Code; doch die Aussage bezieht sich eindeutig auf die Ausführung eines Programms - und das macht sie zu einer falschen.
(Ich hoffe Du hast mittlerweile eingesehen, dass Aussagen sehr wohl Logik beinhalten (können) und daher sehr wohl richtig oder falsch sein können?)

Voraussetzen - nur weil der Mensch das Tool verwendet. Ich bin im sechsten Jahr Tool- und Engine-Entwickler - rein zum Funktionieren braucht meiner Erfahrung nach kein einziges Tool ein GUI. Tests auf Fehler und Funktionalität funktionieren ohne GUI, mit GUI sind die Tests nicht automatisierbar und benötigen menschliche Interaktion (Usability-Tests).

Natürlich kann man auch automatisierte Tests auf dem fertigen und kompletten Programm durchführen! Dafür gibt es gute Werkzeuge a la Selenium für Webanwendungen oder Ranorex als Rundum-sorglos-Paket. Solche Integrationstests sind sogar sehr sinnvoll und sollten ja gerade auf dem wirklich lauffähigen Programm stattfinden.

Und natürlich kann ich als Entwickler für *mein* Programm eine GUI zur Laufzeit zwingend voraussetzen; vielleicht will ich einfach keine Batch-Verarbeitung für meinen Editor schreiben. Damit kannst Du doch gar keine Aussage zum Design und der Code-Qualität an sich treffen!

Fakes gehören ja wohl auch eher in den Bereich Sales, Producing und Marketing....

Die Nomenklatur in dem Bereich geht leider viel durcheinander. Ich fand die Definition von Roy Osherove immer am besten: Fake allgemein für ein Test-Double; Stub für reines Immitieren, Mock für das Auswerten eines Tests. Ich denke darüber muss man nicht wirklich streiten... nenn es doch, wie du willst

[Sophus]

Ich habe es endlich geschafft. Nun, ich möchte mich bei euch so herzlich danken, dass ihr mir geholfen habt. Verspürt ihr Sarkasmus? Dann seid ihr auf dem richtigen Weg. Mein Code sieht wie folgt aus:

Code: Alles auswählen

import sys 
from PyQt4 import QtGui, QtCore 
from Hauptfenster import Ui_Hauptdialog as Dlg
from Dialog import Ui_Dialog2 as Dlg1
     
#Der Hauptdialog, wobei ich eher ein Hauptfenster draus machen wuerde
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." 
            if self.newsletter.checkState(): 
                print "Katalog bestellt" 
            self.close()
    
    def onAbbrechen(self): 
            print "Schade" 
            self.close()
        
    def onNeu(self):
            dialog2 = MeinNeuDialog()
            dialog2.exec_()
    
#Der leere Dialog
class MeinNeuDialog(QtGui.QDialog, Dlg1): 
    def __init__(self): 
        QtGui.QDialog.__init__(self) 
        self.setupUi(self)
    
# Diese Routine ist quasi der Einstiegspunkt fuer das Programm
# if __name__ == '__main__':
# Hier wird eine Instanz der Applikation erstellt
app = QtGui.QApplication(sys.argv)
# Hier wird eine Instanz der Klasse für das Hauptfenster erstellt
winHauptfenster = MeinDialog()
# Mit der Methode showMaximized wird das Hauptfenster maximiert angezeigt
winHauptfenster.exec_()
# Wenn die Instanz winHauptfenster geschlossen wird, dann wird auch die 
# Applikation beendet
# sys.exit(app.exec_())

Nun eine Frage: Ich musste Zeile 50 und 59 "auskommentieren", da das Programm sonst nicht richtig beendet wurde. Dies sah ich am Kommandofenster. Liegt es daran, weil es sich hierbei um Dialoge handelt?

[EmaNymton]

Deine Dialoge werden zwar angezeigt, du dürftest damit aber wenig anfangen können, da du die Hauptschleife, die für das Eventhandling zuständig ist gar nicht ausführst (auskommentierte Zeile 59):
http://pyqt.sourceforge.net/Docs/PyQt4/ ... .html#exec

Dann noch ein paar grundlegende Dinge, die auffallen:

Du kannst du ui-Dateien direkt ohne den Umweg über pyuic einbinden, was imho wesentlich einfacher ist. Dazu gibt es das uic-Modul bei PyQt:
http://pyqt.sourceforge.net/Docs/PyQt4/ ... uic-module

Du schreibst die Connections noch im alten Format, das neuere ist wesentlich lesbarer:
http://pyqt.sourceforge.net/Docs/PyQt4/ ... ng-signals

Zeile 50 auszukommentieren hat erst mal überhaupt keinen Einfluss darauf, ob das Programm läuft oder nicht:
http://abop-german.berlios.de/read/module-name.html

Ich weiß nicht, was bzw. ob du etwas mit den Dialogen bezwecken willst, aber normalerweise beendet man einen Dialog mit accept, reject oder done, nachzulesen in der Dokumentation:
http://pyqt.sourceforge.net/Docs/PyQt4/ ... ml#details

Du solltest dir angewöhnen (Zeile 39-41), Objekte mit self an eine Instanz zu binden oder beim Erzeugen des Dialogs ein parent anzugeben, da im Zweifelsfall das erzeugte Objekt ohne jegliche Referenz einfach gelöscht wird, was zu unschönen Effekten führen kann.

P.S.: Du solltest übrigens nicht mehr das Openbook von Galileo verwenden (daher kommt doch das Beispiel, oder?), das ist eher schlecht, such einfach mal nach Kritik