Seite 1 von 2

Verfasst: Freitag 9. Juni 2006, 19:53
von gerold
SigMA hat geschrieben:Willst du komplett Plattform unabhängig Programmieren solltest du zu wxPython greifen, da das auf _jeder_ Oberfläche gleich ausschaut. Du kann also auf Linux schon sehen wie es unter Windows ausschaut
Hi!

@SigMA: Das kann ich so nicht ganz unterschreiben. wxPython greift unter Linux auf GTK zurück. Deshalb sieht eine wxPython-Anwendung unter Linux so aus wie andere GTK-Anwendungen halt so aussehen. Unter Windows sieht eine wxPython-Anwendung wie jedes andere Windows-Programm aus. Und das ist für viele Windows-DAUs enorm wichtig.

Fakt ist, dass wxPython-Anwendungen von der Oberfläche her unter Linux nicht von nativen GTK-Programmen oder unter Windows nicht von nativen Windows-Programmen unterschieden werden können.

Gefühlter "Fakt" ist, dass wxPython-Programme unter Windows sehr schnell sind und der Aufwand, ein wxPython-Programm auch unter Linux richtig schnell zu halten, sehr gering ist. Lange Listen, mit mehreren 1000 Einträgen sollte man in eine *virtuelle* Liste legen. Genauso auch mit großen Tabellen. Aber dafür ist alles vorbereitet. Man muss es nur verwenden.

Fakt ist, dass ich bis jetzt keine, nicht von mir verschuldeten, Abstürze von wxPython-Programmen beobachtet habe. Ich programmiere mit dem neuesten wxPython und in dem Stil, dass ich nicht alles mit "*" importiere, also auf die neue, empfohlene Art.

Vielleicht hat sich wxPython ja mit den neueren Versionen positiv weiterentwickelt? Ich kann es nicht sagen, da ich erst vor Kurzem zu wxPython gestoßen bin.

Mit einer guten IDE, die ständig anzeigt, welche möglichen Getter- und Setter-Methoden es gibt, ist es wirklich einfach, gut aussehende Programme mit wxPython zu schreiben. Allerdings empfinde ich es erst jetzt so einfach, da ich das Buch gelesen habe. Es macht wirklich einen Unterschied, ob jemand Schritt für Schritt erklärt, wie man ein Programm mit wxPython aufbauen kann und welche Widgets wie bedient werden können, als wenn man sich alles selber zusammensuchen muss.

Dass die Namen der Getter- und Setter-Methoden nicht aus der Luft gegriffen sind und meistens einer ziemlich logischen Namensgebung folgen, sollte dieser Code demonstrieren:

Code: Alles auswählen

textbox = wx.TextCtrl()
textbox.SetBackgroundColour("green")
textbox.SetFocus()
textbox.SetValue("Hallo Welt")
value = textbox.GetValue()
Da sehe ich gewisse Gemeinsamkeiten mit pyGTK.

Warum bin ich nicht bei pyGTK geblieben? Ganz einfach. wxPython stellt für den Entwickler eine ENORME erleichterung dar, da es bei wxPython viele gute Widgets (Steuerelemente) und Dialogfenster gibt, die man sich mit pyGTK mühsam selber zusammenprogrammieren muss.

Hier ein paar Beispiele:

Folgender Code gibt eine zentrierte Dialogbox mit einer Nachricht aus.

Code: Alles auswählen

#!/usr/bin/env python
# -*- coding: utf-8 -*-
import wx

app = wx.PySimpleApp()
wx.MessageBox(
    message = u"Bitte bestätige diese Nachricht mit OK.",
    caption = u"Nachricht"
)
Bei vielen Dialogen gibt es jeweils eine native Dialog-Klasse und eine Kurzform davon.
Klasse: wx.MessageDialog()
Instant-Version: wx.MessageBox()

Die Klasse kann man besser beeinflussen und die Kurzform ist für schnelle Dialoge, ohne Sonderwünsche. Wie man sieht, wird es einem Programmierer wirklich einfach gemacht. Genau das vermisse ich an pyGTK. Die Dinge die man ständig braucht, sind nicht einfach gehalten.

Eine einfache Listbox, also etwas das man ständig braucht, muss man sich mit pyGTK aus "Legosteinen" zusammenbauen, also immer wieder neu erfinden, oder den Code irgendwo sammeln und so wiederverwenden.
Eine InputBox vermisst man komplett. Man muss sich diese, grob gesagt, aus einem Dialog, einem Label und zwei Buttons zusammenbauen.
...

Allerdings, wer nur für Linux oder nur für Gnome Programme schreibt, der sollte natürlich auch das dafür vorgesehene Framework verwenden. Ganz klar. Das war für mich aber nie Thema. Meine Kunden sind typische Windows DAUs und meine Programme müssen primär unter Windows gut laufen. Ich setze ziemlich viel daran, dass meine Programme auch unter Linux lauffähig sind oder werden. Das ist aber (in Anführungszeichen) nur "Hobby". Meine Kunden interessiert das nicht. Und genau für diesen Zweck ist wxPython derzeit die beste Wahl für mich.

So uns jetzt ist Schluss mit dieser Lobesrede. Andere sollen auch noch zu Wort kommen. :twisted:

lg
Gerold
:-)

Verfasst: Dienstag 19. Februar 2008, 14:56
von g4borg
wxPython oder PyQT sind zu empfehlen.

@sigma:
QT ist frei (GPL) wie freiheit, unter jeder plattform, und wx garantiert auch kein gleiches aussehen auf jeder plattform, schon gar nicht windows<->linux... da ist qt sogar besser als wahl, weil es unter jeder plattform gleich auszusehen hat.

Verfasst: Dienstag 19. Februar 2008, 15:39
von Jan-Peer
Hallo,

ich handhabe es ähnlich wie Gerold: Ich entwickele Anwendungen für Kunden, die natürlich bevorzugt Windows einsetzen. Ich dagegen kann es nicht ausstehen, unter Windows zu arbeiten und mache deshalb so viel Entwicklungsarbeit wie möglich von der Linuxseite meines Rechners.
Anfangs habe ich auch mit GTK gearbeitet, bis ich irgendwann entnervt feststellte, daß einige komplexere, in meinen Augen aber elementare Elemente nicht standardmäßig verfügbar waren. Heute bin ich mir sicher, daß diese sich über zusätzliche Bibliotheken problemlos nachrüsten lassen, aber damals habe ich es nicht probiert, und heute habe ich kein Interesse mehr daran. Ich empfinde wxPython als sehr viel angenehmer im Umgang.

Zum Thema gleiches Aussehen unter Linux und Windows möchte ich den folgenden Screenshot beitragen: Er zeigt die Entwicklungsversion eines meiner Programme unter Windows - und einen Designfehler meinerseits, der unter Linux aber nicht auffiel: Die dunkelgrauen "Rahmen" sind unter Linux nicht zu sehen. Ergo: Auch hier kann man sich nicht einfach darauf verlassen, daß es immer so aussieht, wie man es erwartet. Wenn man ein wenig durch die Dokumentation blättert, wird man auch immer wieder Hinweise darauf finden, daß sich bestimmte Kontrollelemente auf den unterschiedlichen Betriebssystemen unterschiedlich verhalten. Das ist kein Problem, so lange man es im Hinterkopf behält und sorgfältig testet.

Bild

Verfasst: Dienstag 19. Februar 2008, 17:56
von numerix
murph hat geschrieben:ich suche zur Zeit eine GUI, die einfach zu Prgrammieren ist.
sie brauch keine großen extras, nur selectboxen jeder art und die standartausgabe.
habe mir tkinter angekuckt und verzeifele. oder ist das normal?
So fing der Thread mal an. Von Tkinter war seitdem hier nichts mehr zu lesen.
Warum nicht? Was spricht gegen Tkinter?

Ich bin noch nicht lange dabei, habe erst einige zaghafte Schritte mit Tkinter gemacht, aber ich fand es gerade nicht zum Verzweifeln, sondern äußerst transparent und nachvollziehbar. Vielleicht liegt das aber einfach daran, dass ich von Java her komme und bisher GUIs mit Swing erstellt habe - alles in Handarbeit. Dagegen ist Tkinter wirklich ein Geschenk (nicht hinsichtlich der Möglichkeiten, aber hinsichtlich der Transparenz und des Aufbaus einer GUI).

Vielleicht liegt es aber auch daran, dass ich noch keine GUIs entsprechender Komplexität mit Tkinter erstellt habe.

Also, nochmal meine Frage an die, die schon reichlich Erfahrung auf diesem Gebiet haben: Was spricht gegen Tkinter?

Verfasst: Dienstag 19. Februar 2008, 18:03
von meneliel
Ich hab mir bisher noch keine andere GUI als Tkinter angeguckt und auch noch nicht wirklich viel mitgemacht. Da ich nur ganz einfaches Fenster mit paar Radiobuttons und Entrys, hat das gereicht. Bin ganz gut damit klar gekommen.

Frage ist eher wie bekommt man hübsche Oberflächen hin. ich find meine immer total hässlich :(

Verfasst: Dienstag 19. Februar 2008, 18:16
von Jan-Peer
Ästethisch wertvolle und / oder komplexere Oberflächen wirst du mit Tkinter nicht hinbekommen. Im Grunde hat es zwei Vorteile: Es ist häufig (bei weitem nicht immer, auch nicht unter Win!) zusammen mit Python installiert worden, und die API ist für ein Toolkit recht angenehm. Wer an der API von Tkinter scheitert, wird mit anderen Toolkits nicht wirklich glücklich werden.

Ich nutze Tkinter, wenn ich schnell mal ne primitive kleine Oberfläche brauche, die eine Installation von wxPython auf dem Zielrechner nicht unbedingt rechtfertigen würde.

Prinzipiell sollte man, wenn man sich mit Oberflächen gleich welcher Art beschäftigen will, objektorientiertes Design und Events verinnerlicht haben. Das macht die ganze Sache doch deutlich einfacher zu verstehen ...

Verfasst: Dienstag 19. Februar 2008, 18:40
von numerix
meneliel hat geschrieben:Frage ist eher wie bekommt man hübsche Oberflächen hin. ich find meine immer total hässlich
Naja, ein bisschen kann man schon machen mit geeigneten Farben usw.
Es muss ja nicht alles nur in Grautönen erscheinen. Aber verglichen mit der Konkurrenz hast du sicherlich recht. ALLERDINGS: Das könnte künftig anders aussehen, denn seit kurzem gibt es Tcl/Tk 8.5 mit neuen Widgets und ich finde, das sieht ganz vielversprechend aus: http://www.tkdocs.com/index.html
Jan-Peer hat geschrieben:Ästethisch wertvolle und / oder komplexere Oberflächen wirst du mit Tkinter nicht hinbekommen.
Wie o.g. könnte sich das mit der Ästhetik ja bald ändern. Warum sollte man keine komplexeren Oberflächen hinbekommen. Ich kann doch mit Frames beliebig schachteln und sehe nicht, was da nicht gehen sollte. Allenfalls könnte man bemängeln, dass die Auswahl der Widgets beschränkt ist.
Da müsste man dann selbst entsprechendes erstellen oder auf Ergänzungen wie Tix oder Tile und was es sonst noch so gibt zurückgreifen. Aber dann wäre aus meiner Sicht auch schon wieder ein Vorteil von Tkinter dahin, nämlich ohne Zusatzinstallation einfach dabei zu sein; zur Not kann man hier die Pakete von ActiveState nutzen, da ist es m.W. immer dabei.
Wer an der API von Tkinter scheitert, wird mit anderen Toolkits nicht wirklich glücklich werden.
Das sehe ich auch so. Ich glaube, wesentlich simpler kann man eine GUI nicht erstellen (lasse mich da aber gerne auch vom Gegenteil überzeugen).

Verfasst: Dienstag 19. Februar 2008, 19:02
von Jan-Peer
Mit 'komplex' meinte ich jetzt nicht die Schachtelungstiefe, sondern Widgets mit größerer Funktionalität wie Listen oder Baumansichten. Oder ein Grid.