¿Qué es mejor para desarrollar aplicaciones de GUI con Haskell, wxWidgets (a través de wxHaskell) o GTK (a través de Gtk2HS)?¿Cuáles son los méritos relativos de wxHaskell y Gtk2HS?
¿Cuáles son los pros y los contras de cada uno? ¿Varía según la plataforma a la que se dirige (yo trabajaría principalmente en OS X pero me gustaría que mis programas también funcionen en Linux y Windows)?
[exención de responsabilidad: Soy un mantenedor wxHaskell]
Ambos son fijaciones GUI estables y bastante completos, y usted puede elegir ya sea para la mayoría de los proyectos con confianza. Ambos tienen algún grado de enlaces Haskell de "nivel superior", pero en ambos casos tendrás que recurrir a una codificación de estilo "C" bastante imperativa para hacer las cosas. Mi impresión es que wxHaskell te permite pasar un poco más de tiempo en las vinculaciones de nivel superior, pero no he hecho mucho GTK2HS, y en cualquier caso, definitivamente te encuentras trabajando en el extremo más fino de la envoltura para ambas bibliotecas: y creo que la "complejidad" total de la programación es similar en ambos casos.
Por lo tanto, tomemos la funcionalidad básica como algo dado y concéntrese en las diferencias. Tenga en cuenta que realmente creo que GTK2HS es una excelente pieza de trabajo, y que será feliz si lo elige. La mayoría de lo que digo a continuación es una visión personal de las diferencias, y por qué elijo trabajar conmigo mismo y con wxHaskell.
GTK2HS tiene un equipo más grande trabajando en él, y se lanza más regularmente. wxHaskell no se actualiza con tanta frecuencia, pero el equipo central está activo y hay correcciones de errores regulares, pero con nuevas funcionalidades más importantes que se agregan más lentamente de lo que nos gustaría (todos tenemos trabajos diurnos).
wxHaskell ofrece una apariencia de aplicación nativa verdadera en todas las plataformas compatibles listas para usar. GTK2HS es, por supuesto, nativo de Linux y tiene un tema nativo bastante bueno en Windows (es decir, lo suficientemente bueno para satisfacer a todos los pedantes ...), pero tiene una apariencia GTK en OSX, y depende de tener instalado X11. Creo que una biblioteca GTK 'nativa' de OSX está en desarrollo, pero se considera relativamente inmadura. Una vez que esto sea estable, GTK2HS debería poder beneficiarse fácilmente de la misma apariencia y sensación "parcialmente nativa" (por ejemplo, GTK OSX screenshot).
wxHaskell es probablemente un poco más fácil de construir si no estás en Linux (GTK2HS es más fácil si estás alojado en Linux), pero ambos son bastante complejos de construir, para ser honestos, ya que hay un número significativo de dependencias en ambos casos.
Es ligeramente más fácil (en mi humilde opinión) distribuir aplicaciones basadas en wxHaskell, simplemente porque tiene menos dependencias de biblioteca. Distribuyo aplicaciones utilizando principalmente InnoSetup en Windows y como paquetes de aplicaciones en OSX. Debo admitir que con solo una pequeña cantidad de trabajo extra, lo mismo podría hacerse con GTK2HS, por lo que este es probablemente el argumento más débil a favor de wxHaskell.
Mi opinión personal es que wxHaskell es más amigable con los desarrollos de código cerrado (por ejemplo, comerciales). Esto es, por supuesto, el tema de las interminables guerras de llamas, por lo que solo diré que wxHaskell está bajo el wxWidgets license, lo que sin ambigüedades permite el desarrollo de código cerrado. GTK2HS es LGPL, por lo que deberá consultar a su abogado, aunque debo aclarar que muchas personas y compañías han llegado a la conclusión de que LGPL es compatible con el desarrollo comercial; los abogados de la empresa para la que trabajo han llegado a la conclusión de que no es apropiado para nuestros proyectos.
Creo que si Linux fuera mi principal plataforma de desarrollo y entrega, probablemente usaría GTK2HS. No es, sin embargo: entrego principalmente a Windows con OSX ocasional, y creo que wxHaskell es una mejor opción para estas plataformas, aunque ambas opciones son compatibles con las tres plataformas.
Espero que esto lo ayude con su elección.
Tengo información bastante incompleta, pero como todavía no tiene respuestas, tal vez la información incompleta es mejor que ninguna.
La pregunta es: ¿es el conjunto de herramientas simplemente un envoltorio alrededor de la funcionalidad tipo C, o hay una capa adicional que le da al kit de herramientas una API más "nativa de Haskell"? Cuando wxHaskell se anunció por primera vez en el taller de Haskell, el desarrollo de la API Haskell nativa parecía extremadamente prometedora, pero aún era incompleta. Parece que todavía se está trabajando en la API "Haskellized" para wxHaskell, mientras que el proyecto Gtk2Hs no menciona este problema en absoluto. Por esa razón, recomendaría a wxHaskell.
Una consideración es que actualmente es un poco más fácil conseguir que wxHaskell trabaje de forma nativa en Mac OS X. GTK2HS depende de GTK, que tiene una implementación usando widgets nativos en Mac OS X, pero esa implementación no se construye tan fácilmente. como lo es la implementación de wxWidgets para Mac OS X.
Por lo tanto, si desea desarrollar código para ejecutar sin X11.app, actualmente está un poco mejor con wxHaskell.
Nota sin embargo, que esto está cambiando rápidamente: http://www.haskell.org/haskellwiki/Gtk2Hs#Using_the_GTK.2B_OS_X_Framework muestra cómo utilizar Gtk2Hs con nativo de GTK + en Mac OS X.
Una ventaja de Gtk2Hs es su apoyo CLARO, por lo que el desarrollo de la sencilla interfaz de usuario muy rápido. Los combinadores de nivel superior en wxHaskell mitigan la mayor parte de esa ventaja, pero requieren una comprensión más profunda de cómo desea que su interfaz se vea y se comporte, y por lo tanto son más difíciles de usar de manera exploratoria.
Personalmente, buscaría algún tipo de paquete reactivo/extensión. Parece sentarse con el paradigma mucho más cerca. En lugar de especificar sus elementos gráficos de manera imperativa, puede hacerlo declarativamente. Ejemplo (no es representativo de cualquier idioma en particular o aplicación):
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 y z se actualizarán automáticamente cada vez que x y el cambio y.
A continuación, podría tener cierta lógica en alguna parte que se ve algo como esto:
if buttonclicked then <do something> else <do something else>
Todo esto es muy difusa sin embargo. Solo mire en algunas interfaces reactivas reales