Das deutsche Python-Forum

Hallo Community,

ich habe gerade erst angefangen Python und Qt/Pyqt zu programmieren, daher frage ich mich nun ob ich es "richtig" mache(Aufteilung der Klassen, Layout usw). Es handelt sich dabei um ein Sudoku Spiel, bzw genauer gesagt Sudoku Löser. Ist aber noch nicht fertig.

http://pastebin.com/hg48J98g

Die Fenstergrößen usw. sind jetzt noch 'hart', werden später aber dynamisch anhand der Bildschirmauflösung des Anwenders angepasst.

Außerdem noch eine Frage, wäre es sinnvoll von QtGui und QtCore nur genau das zu importieren, das ich brauche?

Hat jemand Verbesserungsvorschläge?

Danke im voraus

naeg hat geschrieben: Hat jemand Verbesserungsvorschläge?

Ja. Benutze den Designer, um die GUI zu bauen und lade die dann zur Laufzeit mit dem uic-Modul

Hast Du denn schon den Solver gebaut? Falls ja, super, falls nein: Bitte nicht mit der GUI hart verdrahten, sondern getrennt davon lauffähig machen; Trennung von Logik und GUI ist immer eine gute Idee

Ich bin nicht so begeistert von dem Designer und hab eig schon immer selber Programmieren bevorzugt, und werde es auch weiterhin tun. Ich hab lieber volle Kontrolle über meinen Code. Außerdem handelt es sich dabei um ein Projekt für die Schule, und ich glaube nicht das der Professor will dass ich einen Designer verwende.

Den Solver hab ich noch nicht gemacht, der wird, sobald die GUI fertig ist, in Prolog geschrieben, also ist Logik und GUI so oder so getrennt

@naeg: Volle Kontrolle über Deinen Code behalten zu wollen ist schon in Ordnung, aber den Grossteil von GUI-Design kann man problemlos als Daten ansehen. Solange man nicht Widgets/Layouts aus Informationen zusammensetzt, die nur zur Laufzeit bekannt sind, ist so ein GUI-Design ja eigentlich eine statische Hierarchie von Widgetbeschreibungen.

naeg hat geschrieben:Ich bin nicht so begeistert von dem Designer und hab eig schon immer selber Programmieren bevorzugt, und werde es auch weiterhin tun. Ich hab lieber volle Kontrolle über meinen Code. Außerdem handelt es sich dabei um ein Projekt für die Schule, und ich glaube nicht das der Professor will dass ich einen Designer verwende.

Naja, kommt natürlich drauf an, worauf der Fokus liegt. Ich vertrete die Meinung, dass GUIs von Hand programmiert heutzutage nicht mehr zeitgemäß sind und neben Einbußen an Flexibilität auch schlicht Zeit kosten, die man sich für die wahren Herausforderungen sparen kann.
Natürlich gibt es Ausnahmen, etwa sehr dynamische Elemente o.ä. Aber auch da kann man ja durchaus komponentenweise mit dem Designer arbeiten und die Dynamik durch Integration von Teilelementen realisieren.

naeg hat geschrieben: Den Solver hab ich noch nicht gemacht, der wird, sobald die GUI fertig ist, in Prolog geschrieben, also ist Logik und GUI so oder so getrennt

Coole Sache Nur das Wort "fertig" bereitet mir ein wenig Bauchschmerzen...

Es geht jetzt ja nicht darum zu diskutieren ob ich den Designer verwenden soll oder nicht, da ich ja keine Wahl habe, denn der Professor verlangt es so Den Designer werde ich vlt. bei den nächsten Projekten verwenden. Aber z.b. Sudoku Feld muss ich ja als Widget selber programmieren.

naeg hat geschrieben:Es geht jetzt ja nicht darum zu diskutieren ob ich den Designer verwenden soll oder nicht, da ich ja keine Wahl habe, denn der Professor verlangt es so

Du fragtest nach Verbesserungsvorschlägen und die habe ich gemacht! Diese Einschränkung hast Du jetzt zum ersten Mal als binden erwähnt.

Vielleicht geht es dem Prof ja auch darum zu vermitteln, wie umständlich das von Hand ist? (Ok, vermutlich nicht, sondern er ist da unflexibel )

naeg hat geschrieben: Den Designer werde ich vlt. bei den nächsten Projekten verwenden.

Sehr löblich; schließlich sind die Leute bei Nokia ja auch keine Deppen und denken sich etwas bei ihren Produkten Zudem kannst Du dann sogar selber den Mehrwert einschätzen, weil Du schon Erfahrung beim "von Hand proggen" hast.

naeg hat geschrieben: Aber z.b. Sudoku Feld muss ich ja als Widget selber programmieren.

Naja, auch hier kommt es auf die Idee dahinter an. Man kann sich auch eine Matrix aus Pushbuttons definieren, oder auf ein QTableView setzen, dem Du ein eigenes Model spendierst... es gibt da viele Möglichkeiten.

Evtl. schaust Du dir einfach mal die Idee von kdusoku an?

Hyperion hat geschrieben: Du fragtest nach Verbesserungsvorschlägen und die habe ich gemacht! Diese Einschränkung hast Du jetzt zum ersten Mal als binden erwähnt.

Für die Vorschläge bin ich dir auch dankbar und ich dachte das mit dem Professor kommt so rüber wie ich das jetzt klar gesagt habe

Wie siehts eig mit der Frage zum import aus? Macht das sinnwirklich nur die Widget usw zu importieren die ich brauche?

naeg hat geschrieben:

Hyperion hat geschrieben: Du fragtest nach Verbesserungsvorschlägen und die habe ich gemacht! Diese Einschränkung hast Du jetzt zum ersten Mal als binden erwähnt.

Für die Vorschläge bin ich dir auch dankbar und ich dachte das mit dem Professor kommt so rüber wie ich das jetzt klar gesagt habe

Naja...

naeg hat geschrieben: und ich glaube nicht das der Professor will dass ich einen Designer verwende.

"glauben" ist ja keine wirkliche Einschränkung

Wie siehts eig mit der Frage zum import aus? Macht das sinnwirklich nur die Widget usw zu importieren die ich brauche?

Ich würde sagen nein. Ich persönlich finde die Modulnamen bei Qt ja nun nicht wirklich lang und so weißt Du auch wirklich genau, welches Objekt aus welchem Modul stammt.

Ich persönlich importierte einzelne Klassen, um mir Tipparbeit zu sparen (allerdings nicht mit "*"). Verwendet man den Designer, benötigt man meist kaum mehr als eine Handvoll zusätzlicher Klassen aus QtGui. Ich halte das allerdings für eine Frage des Geschmacks, und nichts, worüber man diskutieren müsste. Nutze einfach, was Dir persönlich besser gefällt.

Die fixen Größenangaben müssen entfallen und durch Layout-Verwaltung ersetzt werden. SudokuField kann direkt von QLabel ableiten, da es eh nicht mehr ist als ein QLabel, die zusätzliche Indirektion ist überflüssig. Ebenso überflüssig ist allerdings der gesamte Ansatz, ein weißes Bild in einem QLabel zur Darstellung eines weißen Felds zu nutzen. Viel einfach und effizienter ist es, einfach ein QWidget mit weißem Hintergrund zu verwenden. Das ist so trivial, dass es dafür eigentlich auch keine eigene Klasse mehr braucht.

Ich persönlich hätte das Sudoku-Feld wahrscheinlich auch gar nicht über Widgets, sondern über QGraphicsView und Konsorten implementiert.

lunar hat geschrieben: Die fixen Größenangaben müssen entfallen und durch Layout-Verwaltung ersetzt werden. SudokuField kann direkt von QLabel ableiten, da es eh nicht mehr ist als ein QLabel, die zusätzliche Indirektion ist überflüssig. Ebenso überflüssig ist allerdings der gesamte Ansatz, ein weißes Bild in einem QLabel zur Darstellung eines weißen Felds zu nutzen. Viel einfach und effizienter ist es, einfach ein QWidget mit weißem Hintergrund zu verwenden. Das ist so trivial, dass es dafür eigentlich auch keine eigene Klasse mehr braucht.

Ich persönlich hätte das Sudoku-Feld wahrscheinlich auch gar nicht über Widgets, sondern über QGraphicsView und Konsorten implementiert.

Wie ich schon erwähnt habe, werden die fixen Größen noch entfernt, ich dachte bisher ich würde es einfach so machen, dass ich die Auflösung des Bildschirms nehme, und damit eine "optimale" Größe des Fensters berechne. Keine gute Idee?

Das Sudoku Feld ist noch nicht fertig, das QLabel ist nur der Hintergrund, darauf werden noch Striche gezeichnet und Eingabefelder in einem Grid angelegt, damit alles auch schon dynamisch ist und sich mit dem Fenster vergrößert. Daher dachte ich mir es ist ein Widget?

naeg hat geschrieben: Wie ich schon erwähnt habe, werden die fixen Größen noch entfernt, ich dachte bisher ich würde es einfach so machen, dass ich die Auflösung des Bildschirms nehme, und damit eine "optimale" Größe des Fensters berechne. Keine gute Idee?

Dazu hat man doch Layoutmanager und den Benutzer selbst. Je nach Auflösung und Präferenz kann er doch selber entscheiden, wie groß er das Fenster ziehen mag und dementsprechend setzt der Layoutmanager dann die innerern Widgets um.

Das habe ich soweit bereits verstanden, jedoch meine ich die Größe des Fensters beim Start des Programms. Die derzeitige Mindestgröße von 330 x 390 ist für meinen Geschmack, auf meinem Bildschirm mit einer Auflösung von 1680x1050 bzw 1920x1080, zu klein.

Ach so... na dann definiere einfach keine Mindestgröße Oder nimm etwas gängiges wie 640x480 o.ä.