Quels sont les mérites relatifs des wxHaskell et gtk2hs?

Question

Ce qui est mieux pour le développement d'applications de l'interface graphique avec Haskell, wxWidgets (via wxHaskell ) ou GTK (via < a href = "http://www.haskell.org/gtk2hs/" rel = "noreferrer"> gtk2hs )?

Quels sont les avantages et les inconvénients de chacun? Est-il varie en fonction de la plate-forme que vous visez (je travaillerai principalement sur OS X, mais voudrais que mes programmes pour travailler sur Linux et Windows aussi)?

Answer 1

[Avertissement: Je suis responsable wxHaskell]

sont deux liaisons GUI stables et assez complètes, et vous pouvez choisir soit pour la plupart des projets avec confiance. Tous les deux ont un certain degré de liaisons Haskell « plus haut niveau », mais dans les deux cas, vous devrez tomber dans le codage de style « C » plutôt impératif de faire avancer les choses. Mon impression est que wxHaskell vous permet de passer un peu plus de temps dans les liaisons plus haut niveau, mais je n'ai pas fait beaucoup gtk2hs, et en tout état de cause, vous trouverez certainement vous travailler sur l'extrémité mince de l'enveloppe pour les deux bibliothèques - et je pense que la « complexité » la programmation globale est similaire dans les deux cas.

Par conséquent, nous allons prendre les fonctionnalités de base comme donnée et de se concentrer sur les différences. S'il vous plaît noter que je crois sincèrement que gtk2hs est un excellent travail, et que vous serez heureux si vous le choisissez. La plupart de ce que je dis ci-dessous est un point de vue personnel sur les différences, et pourquoi je choisis de travailler sur et avec wxHaskell moi-même.

gtk2hs a une plus grande équipe travaillant sur elle, et est libéré plus régulièrement. wxHaskell est pas mis à jour aussi souvent, mais l'équipe de base est actif, et il y a des corrections de bugs réguliers, mais avec de nouvelles fonctionnalités majeure ajoutée un peu plus lentement que nous voudrions (nous avons tous les emplois de jour).

wxHaskell donne la vraie apparence de l'application native sur toutes les plateformes prises en charge hors de la boîte. Gtk2hs est, bien sûr, natif sur Linux et a un très bon thème natif sur Windows (à savoir assez bon pour satisfaire tous mais pédants ...), mais a apparence GTK sur OSX, et dépend d'avoir installé X11. Je crois qu'une bibliothèque GTK « native » OSX est en cours de développement, mais elle est considérée comme relativement immature. Une fois que cela est stable, gtk2hs devraient pouvoir bénéficier facilement du même aspect « partiellement indigène » et se sentent (par exemple GTK OSX capture d'écran ).

wxHaskell est probablement un peu plus facile à construire si vous n'êtes pas sur Linux (gtk2hs est probablement plus facile si vous êtes Linux hébergé), mais les deux sont assez complexes à construire, pour être honnête, car il y a un nombre important de dépendances dans les deux cas.

Il est un peu plus facile (à mon humble avis) pour distribuer des applications basées sur wxHaskell, simplement parce qu'il a moins de dépendances. Je distribue principalement des applications utilisant InnoSetup sous Windows, et sous forme de faisceaux App sur OSX. J'avoue que, avec seulement une petite quantité de travail supplémentaire, la même chose pourrait être fait avec gtk2hs, il est sans doute le plus faible argument en faveur de wxHaskell.

Il est mon opinion personnelle que wxHaskell est plus favorable à la source fermée de développements (par exemple commerciales). Ceci est, bien sûr, le sujet des guerres de flamme interminables, alors je vais seulement dire que wxHaskell est sous la licence wxWidgets qui permet sans ambiguïté pour le développement des sources fermées. Gtk2hs est LGPL, vous aurez donc besoin de demander à votre avocat - même si je dois préciser que beaucoup de gens et les entreprises ont conclu que LGPL est compatible avec le développement commercial; les avocats de l'entreprise où je travaille ont conclu qu'il est inapproprié pour nos projets.

Je pense que si Linux était ma principale plate-forme de développement et de livraison, je serais probablement utiliser gtk2hs. Il est cependant pas. Je livre principalement à Windows avec Mac OS X occasionnelle, et je pense que wxHaskell est une meilleure adéquation à ces plates-formes, bien que les deux options prennent en charge les trois plates-formes

J'espère que cela vous aidera dans votre choix.

Answer 2

Une considération est qu'actuellement il est un peu plus facile d'obtenir wxHaskell travailler en mode natif sur Mac OS X. gtk2hs dépend de GTK, qui ne dispose d'une mise en œuvre en utilisant des widgets natifs sous Mac OS X, mais que la mise en œuvre est pas aussi facilement construit comme la mise en œuvre wxWidgets pour Mac OS X est.

Par conséquent, si vous voulez développer un code pour fonctionner sans X11.app, actuellement vous êtes un peu mieux avec wxHaskell.

Notez cependant que cela est en train de changer rapidement: http://www.haskell.org/haskellwiki/Gtk2Hs#Using_the_GTK.2B_OS_X_Framework montre comment utiliser gtk2hs avec + natif GTK sous Mac OS X.

L'un des avantages de gtk2hs est son soutien GLADE, ce qui rend le développement de l'interface utilisateur simple, très rapide. Les combinateurs de niveau supérieur dans la plupart des wxHaskell atténuer cet avantage, mais ils exigent une meilleure compréhension de la façon dont vous voulez que votre interface pour regarder et se comporter, et sont donc plus difficiles à utiliser de façon exploratoire.

Answer 3

J'ai assez d'informations incomplètes, mais puisque vous n'avez pas encore de réponse, peut-être des informations incomplètes est mieux que rien.

La question à poser est la suivante: est la boîte à outils juste une enveloppe autour de la fonctionnalité C-like, ou est-il une couche supplémentaire qui donne la boîte à outils une plus API « native Haskell-like »? Lorsque wxHaskell a d'abord été annoncé à l'atelier Haskell, le développement de l'API native Haskell avait l'air très prometteur, mais il était encore incomplet. Il semble que l'API « Haskellized » pour wxHaskell est encore en cours d'élaboration, alors que le projet gtk2hs ne mentionne pas cette question du tout. Pour cette raison, je vous recommande wxHaskell.

Answer 4

Personnellement, je regarderais dans une sorte de paquet réactive / l'extension. Il semble s'asseoir avec le paradigme beaucoup plus proche. Au lieu de spécifier vos trucs graphiques impérieusement, vous pouvez le faire déclarative. Exemple (pas représentatif d'une langue particulière ou la mise en œuvre):

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)

ButtonClicked et z sera mis à jour automatiquement à chaque fois que x et y changer.

Vous pourriez alors avoir une certaine logique quelque part qui ressemble à ceci:

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

Ceci est d'autant que très floue. Il suffit de regarder dans certaines interfaces réelles réactives