Was sind die relativen Vorzüge von wxHaskell und Gtk2HS?

Question

Was ist besser für die Entwicklung von GUI-Anwendungen mit Haskell, wxWidgets (über wxHaskell ) oder GTK (über Gtk2HS )?

Was sind die Vor- und Nachteile der beiden? Gibt es Unterschiede, je nachdem, auf welche Plattform Sie abzielen (ich würde in erster Linie unter OS X arbeiten, möchte aber, dass meine Programme auch unter Linux und Windows funktionieren)?

Answer 1

[Haftungsausschluss: Ich bin ein wxHaskell-Maintainer]

Beide sind stabile und ziemlich vollständige GUI-Bindings, und man kann sich für die meisten Projekte getrost für eines der beiden entscheiden. Beide haben ein gewisses Maß an "higher-level" Haskell Bindungen, aber in beiden Fällen müssen Sie in eher imperativen "C" Stil kodieren, um die Dinge zu erledigen. Mein Eindruck ist, dass wxHaskell erlaubt es Ihnen, ein wenig mehr Zeit in der höheren Ebene Bindungen zu verbringen, aber ich habe nicht viel GTK2HS getan, und in jedem Fall finden Sie sich definitiv auf das dünne Ende der Wrapper für beide Bibliotheken arbeiten - und ich denke, die gesamte Programmierung "Komplexität" ist in beiden Fällen ähnlich.

Nehmen wir also die Grundfunktionalität als gegeben an und konzentrieren uns auf die Unterschiede. Bitte beachten Sie, dass ich aufrichtig davon überzeugt bin, dass GTK2HS eine hervorragende Arbeit ist und dass Sie glücklich sein werden, wenn Sie sich dafür entscheiden. Das meiste, was ich im Folgenden sage, ist eine persönliche Sichtweise der Unterschiede und der Gründe, warum ich selbst an und mit wxHaskell arbeiten möchte.

GTK2HS hat ein größeres Team, das daran arbeitet, und wird regelmäßiger veröffentlicht. wxHaskell wird nicht so häufig aktualisiert, aber das Kernteam ist aktiv, und es gibt regelmäßige Bugfixes, aber größere neue Funktionen werden etwas langsamer hinzugefügt, als wir es gerne hätten (wir haben alle Tagesjobs).

wxHaskell bietet ein echtes natives Erscheinungsbild der Anwendung auf allen unterstützten Plattformen von Haus aus. GTK2HS ist natürlich nativ auf Linux und hat ein ziemlich gutes natives Thema auf Windows (d.h. gut genug, um alle außer Pedanten zu befriedigen...), hat aber GTK Look and Feel auf OSX und hängt davon ab, dass X11 installiert ist. Ich glaube, dass eine OSX-'native' GTK-Bibliothek in Entwicklung ist, aber als relativ unreif gilt. Sobald diese stabil ist, sollte GTK2HS in der Lage sein, von demselben 'teilweise nativen' Look and Feel zu profitieren (z.B. GTK OSX Bildschirmfoto ).

wxHaskell ist wahrscheinlich ein wenig einfacher zu bauen, wenn Sie nicht auf Linux sind (GTK2HS ist wahrscheinlich einfacher, wenn Sie Linux gehostet werden), aber beide sind ziemlich komplex zu bauen, um ehrlich zu sein, da es eine erhebliche Anzahl von Abhängigkeiten in beiden Fällen sind.

Es ist (IMHO) etwas einfacher, Anwendungen auf Basis von wxHaskell zu verteilen, einfach weil es weniger Bibliotheksabhängigkeiten gibt. Ich verteile Anwendungen hauptsächlich mit InnoSetup unter Windows und als App-Bundles unter OSX. Ich würde zugeben, dass mit nur geringem Mehraufwand das Gleiche mit GTK2HS gemacht werden könnte, also ist dies wahrscheinlich das schwächste Argument zugunsten von wxHaskell.

Ich persönlich bin der Meinung, dass wxHaskell für Closed-Source-Entwicklungen (z.B. kommerzielle) besser geeignet ist. Dies ist natürlich das Thema endloser Flamewars, daher möchte ich nur sagen, dass wxHaskell unter dem wxWidgets-Lizenz die eindeutig eine Entwicklung mit geschlossenem Quellcode zulässt. GTK2HS steht unter der LGPL, also müssen Sie Ihren Anwalt fragen - obwohl ich klarstellen muss, dass viele Menschen und Unternehmen zu dem Schluss gekommen sind, dass die LGPL mit kommerzieller Entwicklung vereinbar ist; die Anwälte des Unternehmens, für das ich arbeite, sind zu dem Schluss gekommen, dass sie für unsere Projekte ungeeignet ist.

Ich denke, wenn Linux meine Hauptentwicklungs- und Auslieferungsplattform wäre, würde ich wahrscheinlich GTK2HS verwenden. Ist es aber nicht: Ich liefere hauptsächlich für Windows und gelegentlich für OSX, und ich denke, wxHaskell passt besser zu diesen Plattformen, obwohl beide Optionen alle drei Plattformen unterstützen.

Ich hoffe, dies hilft Ihnen bei Ihrer Wahl.

Answer 2

Eine Überlegung ist, dass es derzeit etwas einfacher ist, wxHaskell nativ unter Mac OS X zum Laufen zu bringen. GTK2HS hängt von GTK ab, das eine Implementierung mit nativen Widgets für Mac OS X hat, aber diese Implementierung ist nicht so einfach zu erstellen wie die wxWidgets-Implementierung für Mac OS X.

Wenn Sie also Code entwickeln wollen, der ohne X11.app läuft, sind Sie derzeit mit wxHaskell etwas besser dran.

Dies ändert sich jedoch rasch: http://www.haskell.org/haskellwiki/Gtk2Hs#Using_the_GTK.2B_OS_X_Framework zeigt, wie man GTK2HS mit nativem GTK+ unter Mac OS X verwendet.

Ein Vorteil von GTK2HS ist die GLADE-Unterstützung, die die Entwicklung von einfachen Benutzeroberflächen sehr schnell macht. Die Kombinatoren auf höherer Ebene in wxHaskell gleichen diesen Vorteil größtenteils aus, aber sie erfordern ein tieferes Verständnis dafür, wie Ihre Benutzeroberfläche aussehen und sich verhalten soll, und sind daher schwieriger in einer explorativen Weise zu verwenden.

Answer 3

Ich habe ziemlich unvollständige Informationen, aber da Sie noch keine Antworten haben, sind unvollständige Informationen vielleicht besser als keine.

Die Frage, die man sich stellen muss, ist folgende: Ist das Toolkit nur ein Wrapper um eine C-ähnliche Funktionalität, oder gibt es eine zusätzliche Schicht, die dem Toolkit eine "native Haskell-ähnliche" API verleiht? Als wxHaskell zum ersten Mal auf dem Haskell-Workshop angekündigt wurde, sah die Entwicklung der nativen Haskell-API äußerst vielversprechend aus, war aber noch nicht abgeschlossen. Es sieht so aus, als ob an der "haskellisierten" API für wxHaskell immer noch gearbeitet wird, während das Gtk2Hs-Projekt dieses Thema überhaupt nicht erwähnt. Aus diesem Grund würde ich wxHaskell empfehlen.

Answer 4

Ich persönlich würde eine Art von Reactive-Paket/Erweiterung in Betracht ziehen. Es scheint zu sitzen mit dem Paradigma viel viel näher. Anstatt die grafischen Elemente zwingend zu spezifizieren, kann man sie deklarativ festlegen. Beispiel (nicht repräsentativ für eine bestimmte Sprache oder Implementierung):

x, y, z              :: Int
click, buttonclicked :: Bool
x = <X coordinate of mouse>
y = <Y coordinate of mouse>
click = <Whether mouse button is currently being pressed>
z = x + y
buttonclicked = (x == 10 && y == 10 && click)

Wenn Sie auf die Schaltfläche klicken, wird z automatisch aktualisiert, sobald sich x und y ändern.

Sie könnten dann irgendwo eine Logik haben, die in etwa so aussieht:

if buttonclicked then <do something> else <do something else>

Allerdings ist das alles sehr unscharf. Schauen Sie sich einfach ein paar echte reaktive Schnittstellen an