Suggestions pour une bibliothèque GUI à Haskell [fermé]

Comme le dit le Haskell Wiki lui-même :

Il existe un grand nombre de bibliothèques GUI pour Haskell. Malheureusement, il n'y en a pas de standard et tous sont plus ou moins incomplets. En général, les placages de bas niveau vont bien, mais ils sont de bas niveau. Les abstractions de haut niveau sont assez expérimentales. Il existe un besoin pour une bibliothèque d'interface graphique de niveau moyen prise en charge.

Un professeur de mon collège m'a demandé, ainsi qu'à trois autres majors en informatique, d'envisager de travailler sur une bibliothèque graphique pour Haskell. Son idée initiale pour le projet était d'écrire une couche sur OpenGL qui imite la bibliothèque morphique trouvée dans Smalltalk ; cependant, ce n'est qu'une suggestion et d'autres systèmes méritent d'être pris en considération.

Cela nous amène à la question réelle en plusieurs parties.

1. Pour quel niveau d'abstraction notre bibliothèque devrait-elle s'efforcer? Le Haskell Wiki semble indiquer fortement qu'une bibliothèque GUI de niveau moyen serait préférée; cependant, une bibliothèque de haut niveau serait toujours la bienvenue.
2. Sur quoi construire notre bibliothèque? (Ex. OpenGL)
3. Quelle bibliothèque graphique existante aimeriez-vous voir notre imitation de bibliothèque (le cas échéant) et pourquoi? (Ex. PyGame, Morphic, Swing, etc.)
4. Quelles fonctionnalités aimeriez-vous voir notre bibliothèque implémenter ou éviter? Par exemple, les bonnes personnes de Gnome pourraient affirmer que le bouton de réduction n'est pas nécessaire.
5. Avez-vous des suggestions générales?
6. Quel nom intelligent donneriez-vous à cette bibliothèque imaginaire? (Ex. HOT - Haskell Opengl Toolkit; HAWT - Haskell Advanced Windowing Toolkit)

J'aimerais voir une bibliothèque élégante et simple à utiliser avec Haskell. Le reste, ce sont des détails techniques qui devraient servir à cet effet, pas le redéfinir. Ainsi mes 0,02 $.

Ne le basez pas sur une boîte à outils existante , comme Qt ou GTK ou FLTK ou ... - cela vous limitera considérablement et vous causera probablement beaucoup plus de douleur que de profit. PyQt est, euh, assez drôle et artificiel, et Python et C ++ sont des langages OO impératifs extrêmement flexibles. Dans le cas de Haskell, les choses seraient beaucoup plus difficiles, je suppose.

Ne dépendez que des primitives graphiques les plus élémentaires , puis tirez parti de cela. OpenGL est bien, mais même quelque chose de plus simple (2D uniquement, par exemple SDL) ferait bien aussi. Cela vous donnera une flexibilité maximale et une portabilité maximale. Voir Smalltalk / Morphic, Java / Swing, TCL / Tk.

Rendez-le conceptuellement petit. Les interfaces graphiques sont difficiles comme elles sont, pas besoin d'ajouter un autre Everest pour grimper. Haskell, j'espère, peut aider à rendre la chose compacte et modulaire.

Pour les points bonus, rendez-le skinnable. Au minimum, sachez comment appliquer des couleurs système (et uniquement des couleurs système) pour peindre l'ensemble de votre répertoire de contrôles, afin qu'une application créée avec cette boîte à outils ne soit pas une horreur. Au maximum, sachez comment faire en sorte que Win32 / Gtk / Qt / Cocoa dessine vos contrôles pour qu'ils soient entièrement natifs. La skinnability de base est simple et logique; atteindre un aspect natif complet est assez difficile.

Aussi, veuillez exécuter rootless et laisser la gestion des fenêtres au système graphique sous-jacent - X, Windows, peu importe. Ne pas le faire mettra en cause la santé mentale des utilisateurs et entravera considérablement l'adoption.

Comme d'habitude, «rendre les choses simples simples et complexes possibles» + «éviter le tarpit de Turing où tout est possible mais rien d'intéressant n'est simple» + «rendre le plus simple possible mais pas plus simple».

Le nom est la chose la moins importante. De toutes les boîtes à outils GUI populaires, seul Qt a un nom intelligent. Un certain nombre de projets populaires ont changé de nom, même en vol (Firefox, née Firebird). Ayez quelque chose à nommer et vous le nommerez.

Bonne chance!

Après avoir parlé à tous les étudiants impliqués et avoir donné à cette question suffisamment de temps pour susciter l'intérêt, je pense que nous sommes parvenus à un consensus sur quelques-unes des questions clés de mon message d'origine.

Pour quel niveau d'abstraction notre bibliothèque devrait-elle s'efforcer? Le Haskell Wiki semble indiquer fortement qu'une bibliothèque GUI de niveau moyen serait préférée; cependant, une bibliothèque de haut niveau serait toujours la bienvenue.

Nous avons décidé de viser une bibliothèque de niveau moyen selon la suggestion du Haskell Wiki.

Sur quoi construire notre bibliothèque? (Ex. OpenGL)

Nous avons choisi OpenGL en raison de sa popularité et de son support. Nous utiliserons soit la GLUT ou GLFW wrapper projets Haskell comme une base.

Quelle bibliothèque graphique existante aimeriez-vous voir notre imitation de bibliothèque (le cas échéant) et pourquoi? (Ex. PyGame, Morphic, Swing, etc.)

Nous avons choisi Morphic après un long débat entre lui et PyGame. Nous n'avons pas considéré QT ou GTK car les deux ont déjà un ou plusieurs projets de bibliothèque Haskell en développement actif .

Quel nom intelligent donneriez-vous à cette bibliothèque imaginaire? (Ex. HOT - Haskell Opengl Toolkit; HAWT - Haskell Advanced Windowing Toolkit)

C'est encore à débattre. Nous avons décidé de ne pas considérer HAWT et examinons plutôt:

• HOT - Boîte à outils Haskell Opengl
• HOG - Haskell Opengl Graphics (Faites votre projet propulsé par HOG!)
• Schön