Nous avons une grande demande de console à Haskell que j'ai été chargée de faire une plate-forme transversale et d'ajouter une interface graphique.
Les exigences sont:
Maintenant, la vraie raison de cette question est d'expliquer une solution que je recherche à l'heure actuelle et de solliciter pour des raisons que je ne pense pas à cela faire une mauvaise idée.
Ma solution est une interface graphique native. Winforms sur Windows, Cocoa sur Mac OS X et GTK / Glade sur Linux, qui gère simplement la présentation. Ensuite, j'écrirais un calque sur le code Haskell qui le transforme en un répondant pour les messages vers et à partir de l'interface utilisateur avec Zeromq pour gérer les messages et peut-être des protobufs pour sérialiser les données d'avant en arrière. Donc, l'application native démarrerait qui démarrerait elle-même le démon où toute la magie se produit et envoie des messages d'avant en arrière.
En plus de s'assurer que le démon accepte uniquement les connexions de l'application qui l'a débute et le défi de fournir les données appropriées pour les éléments d'interface graphique avancée (je pense que les vues de table, les cellules, etc.), je Ne vois pas beaucoup de descente à cela.
Qu'est-ce que je ne pense pas à cela en fait une mauvaise idée?
Je devrais probablement mentionner qu'au premier abord, j'allais aller avec GTK sur toutes les plateformes. Le problème est que, bien qu'il soit proche, et que le soutien de GTK et de Glade pour Haskell est agréable de travailler avec, le résultat n'a pas l'air "juste". Il est étroit, mais il n'est tout simplement pas assez indigène de manière subtile, ce qui rend cette solution inacceptable pour les personnes qui arrivent à écrire le chèque de ce travail.
En outre, la question de plusieurs plates-formes et donc plusieurs langues pour l'interface graphique n'est pas un problème, je ne suis donc pas nécessairement à la recherche d'autres moyens de résoudre ce problème à moins que cela ne simplifie quelque chose sur l'interopie avec le code HASKELL.
4 Réponses :
Ensuite, j'écrirais un calque sur le code Haskell qui le transforme en un répondant pour les messages vers et à partir de l'interface utilisateur avec Zeromq pour gérer le messages et peut-être des protobufs pour sérialiser les données d'avant en arrière.
Je pense que cela est raisonnable (modèle client / serveur, où le client juste se trouve être une application de bureau d'apparence native). (Je n'ai pas de vue forte sur ProTobufs contre E.G. Json, épargne).
Le Haskell Zeromq les liaisons obtiennent Certaines utilisent maintenant aussi.
Qu'est-ce que je ne pense pas à cela en fait une mauvaise idée?
Dans quelle mesure le test de zeromq est-il bien testé sur Windows et Mac? C'est probablement bien, mais quelque chose que je vérifiais.
Le problème est que, s'il est proche, et GTK et Glade Support pour Haskell est agréable de travailler avec, le résultat n'a pas l'air «à droite».
Est-ce que le Package d'intégration aide là-bas?
Donc, votre raison de ne pas utiliser une application Web est en raison de la nature sensible de la sortie du programme Haskell. Et c'est pourquoi vous distribuez cette même application sensible qui ressort de données non cryptées sur toutes les machines clientes? Ça n'a aucun sens.
Si votre application est sensible, vous devez définir le serveur et utiliser le plus fort possible TLS .
Voici une possibilité intéressante: Wai-Handler-webkit . Il incombe essentiellement à QtwebKit avec le serveur Web Warp pour rendre vos applications Web déployables. Il n'a pas été utilisé à une utilisation intensive, n'a jamais été testé sur Mac et est délicat pour compiler sur Windows, mais c'est une approche assez simple qui vous permet d'utiliser l'écosystème Web assez riche en développant Haskell.
Je vais probablement faire plus de développement sur celui-ci dans un proche avenir, donc si vous êtes intéressé à l'utiliser, permettez-moi de savoir quelles fonctionnalités supplémentaires seraient utiles, ainsi que si vous pouviez offrir une aide sur le Mac avant en particulier. Je ne suis pas non plus convaincu que nous devions coller avec Qtwebkit sur toutes les plateformes: il peut avoir plus de sens d'utiliser un backend WebKit différent en fonction du système d'exploitation, ou peut-être même à l'aide de gecko ou (frighder) Trident.
Je me suis bien gêné dans un moment de retour avec Hack-Handler-webkit, ou quelque chose comme ça. Cela a très bien fonctionné. Dès que j'obtiendrai un peu de temps libre, je vais certainement rechercher cela. Merci pour l'info!
J'ai eu quelques problèmes à faire de Zeromq de jouer à Haskell sur OSX (problèmes de recherche d'une dylib, par opposition à un "O", je pense). Les tampons de protocole et Haskell semble bien fonctionner.