¿Cuáles son los méritos relativos de wxHaskell y Gtk2Hs?

Question

¿Qué es mejor para el desarrollo de aplicaciones GUI con Haskell, wxWidgets (a través de wxHaskell ) o GTK (a través de < a href = "http://www.haskell.org/gtk2hs/" rel = "noreferrer"> Gtk2Hs )?

¿Cuáles son los pros y los contras de cada uno? ¿Varía dependiendo de la plataforma que se dirigen (I principalmente estaría trabajando en OS X, pero me gustaría que mis programas para trabajar en Linux y Windows también)?

Answer 1

[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 un cierto grado de enlaces de Haskell 'más alto nivel', pero en ambos casos se tendrá que colocar en lugar imprescindible codificación estilo 'C' para hacer las cosas. Mi impresión es que wxHaskell le permite pasar un poco más de tiempo en los enlaces de más alto nivel, pero no he hecho mucho Gtk2Hs, y en cualquier caso, que sin duda se encuentra trabajando en el extremo delgado de la envoltura de las dos bibliotecas - y creo que la programación general 'complejidad' es similar en ambos casos.

Por lo tanto, vamos a dar la funcionalidad básica como un dado y se concentran en las diferencias. Tenga en cuenta que yo realmente creo que Gtk2Hs es una excelente pieza de trabajo, y que va a ser feliz si lo elige. La mayor parte de lo que digo a continuación es una visión personal sobre las diferencias y por qué elegir para trabajar en y con wxHaskell mí mismo.

Gtk2Hs tiene un equipo más grande que trabaja en ella, y se libera con más regularidad. wxHaskell no se actualiza con la frecuencia, pero el equipo principal está activo, y hay correcciones regulares, pero con gran funcionalidad nueva que se añade un poco más lentamente de lo que quisiéramos (todos tenemos trabajos del día).

wxHaskell da verdadera apariencia aplicación nativa en todas las plataformas soportadas fuera de la caja. Gtk2Hs es, por supuesto, nativa en Linux y tiene un muy buen tema nativa en Windows (es decir, lo suficientemente bueno como para satisfacer todos menos pedantes ...), pero tiene GTK verse y sentirse en OSX, y depende de haber instalado X11. Creo que la biblioteca 'nativo' GTK un OSX está en desarrollo, pero se considera relativamente inmaduro. Una vez que esto es estable, Gtk2Hs deben poder beneficiarse fácilmente de la misma expresión 'parcialmente nativa' y se sienten (por ejemplo, GTK OSX pantalla ).

wxHaskell es probablemente un poco más fácil de construir si no está en Linux (Gtk2Hs probablemente más fácil si usted es Linux alojado), pero ambos son bastante complejas para construir, para ser honesto, ya que hay un número significativo de dependencias en ambos casos.

Es un poco más fácil (en mi humilde opinión) para distribuir aplicaciones basadas en wxHaskell, simplemente porque tiene un menor número de dependencias de bibliotecas. Distribuyo aplicaciones utilizando principalmente InnoSetup en Windows, y como aplicación lía en OSX. Me admitir que con sólo una pequeña cantidad de trabajo extra, el mismo podría hacerse con Gtk2Hs, por lo que este es probablemente el argumento más débil en favor de wxHaskell.

Es mi opinión personal que wxHaskell es más amigable con los desarrollos de código cerrado (por ejemplo comerciales). Esto es, por supuesto, el tema de interminables guerras de la llama, así que sólo voy a decir que wxHaskell está bajo el rel="noreferrer"> Licencia wxWidgets que permite de forma inequívoca para el desarrollo de código cerrado. Gtk2Hs es LGPL, por lo que tendrá que preguntar a su abogado - aunque hay que dejar claro que muchas personas y empresas han llegado a la conclusión de que LGPL es compatible con el desarrollo comercial; los abogados de la empresa donde trabajo han llegado a la conclusión de que no es apropiado para nuestros proyectos.

Creo que si Linux era mi principal plataforma de desarrollo y entrega, probablemente haría uso de Gtk2Hs. Sin embargo, no es,:. Entrego principalmente a Windows con OSX ocasional, y creo que wxHaskell es un partido mejor para estas plataformas, aunque ambas opciones son compatibles con todas las plataformas de tres

Espero que esto le ayudará con su elección.

Answer 2

Una consideración es que en la actualidad es un poco más fácil de conseguir wxHaskell a trabajar de forma nativa en Mac OS X. Gtk2Hs depende de GTK, que tiene una implementación usando widgets nativos en Mac OS X, pero que la aplicación no se construye con tanta facilidad como la aplicación wxWidgets para Mac OS X es.

Por lo tanto, si se quiere desarrollar código para funcionar sin X11.app, actualmente está ligeramente mejor con wxHaskell.

Recuerde que esto es rápidamente cambiando: http://www.haskell.org/haskellwiki/Gtk2Hs#Using_the_GTK.2B_OS_X_Framework muestra cómo utilizar Gtk2Hs con GTK + nativa en Mac OS X.

Una de las ventajas de Gtk2Hs es su apoyo CLARO, por lo que el desarrollo de la interfaz de usuario sencilla muy rápido. Los combinadores de más alto nivel en wxHaskell mitigar la mayor parte de esa ventaja, pero sí requieren una comprensión más profunda de cómo quiere que su interfaz de mirar y comportarse, y por lo tanto son más difíciles de usar a manera de exploración.

Answer 3

Tengo información muy incompleta, pero ya que no tienen respuesta aún, tal información incompleta es mejor que nada.

La pregunta es la siguiente: es el conjunto de herramientas sólo un envoltorio alrededor de una funcionalidad similar a C, o hay una capa adicional que proporciona el conjunto de herramientas de un "Haskell-como nativo" API más? Cuando wxHaskell fue anunciado por primera vez en el taller Haskell, el desarrollo de la API nativa Haskell parecía muy prometedor, pero aún estaba incompleta. Parece como si la API "Haskellized" para wxHaskell todavía se está trabajando, mientras que el proyecto Gtk2Hs no menciona este problema en absoluto. Por eso me gustaría recomendar wxHaskell.

Answer 4

En lo personal me gustaría ver en una especie de reactivo paquete / extensión. Parece que sentarse con el paradigma mucho más cerca. En lugar de especificar su materia gráfica imperativamente, puede hacerlo de forma declarativa. 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 actualiza automáticamente cada vez que x y el cambio y.

A continuación, podría tener cierta lógica en alguna parte que es como la siguiente:

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

Todo esto es muy difusa sin embargo. Basta con mirar en algunas interfaces reales reactivos