Sugerencias para una biblioteca de GUI en Haskell [cerrado]

14

Como dice el la propia Wiki de Haskell :

  

Hay un gran número de bibliotecas GUI para Haskell. Desafortunadamente, no hay uno estándar y todos están más o menos incompletos. En general, las carillas de bajo nivel van bien, pero son de bajo nivel. Las abstracciones de alto nivel son bastante experimentales. Se necesita una biblioteca de GUI de nivel medio compatible.

Un profesor de mi universidad me pidió a mí ya otras tres carreras de informática que consideraran trabajar en una biblioteca de GUI para Haskell. Su idea inicial para el proyecto fue escribir una capa sobre OpenGL que imitara la biblioteca mórfica encontrada en Smalltalk ; sin embargo, esto es solo una sugerencia y definitivamente vale la pena considerar otro sistema.

Esto nos lleva a la pregunta real, en varias partes.

  1. ¿A qué nivel de abstracción debería esforzarse nuestra biblioteca? El Wiki de Haskell parece indicar claramente que se preferiría una biblioteca de GUI de nivel medio; sin embargo, una biblioteca de alto nivel aún sería bienvenida.
  2. ¿Sobre qué debería construirse nuestra biblioteca? (Ej. OpenGL)
  3. ¿Qué biblioteca de GUI existente le gustaría ver como mímico de nuestra biblioteca (si existe) y por qué? (Por ejemplo, PyGame, Morphic, Swing, etc.)
  4. ¿Qué características le gustaría que nuestra biblioteca implementara o evitara? Por ejemplo, la buena gente de Gnome podría argumentar que el botón de minimizar no es necesario.
  5. ¿Tiene alguna sugerencia general?
  6. ¿Qué nombre inteligente le darías a esta biblioteca imaginaria? (Por ejemplo, HOT - Haskell Opengl Toolkit; HAWT - Haskell Advanced Windowing Toolkit)
pregunta Bface 21.03.2011 - 02:19

2 respuestas

7

Me gustaría ver una biblioteca que sea elegante y fácil de usar con Haskell. El resto son detalles técnicos que deben servir para este propósito, no para redefinirlo. Así mi $ 0.02.

No lo base en un conjunto de herramientas existente , como Qt o GTK o FLTK o ... - esto lo limitará severamente y probablemente le dará mucho más dolor que beneficio. PyQt es, erm, divertido y lo suficientemente ingenioso, y tanto Python como C ++ son lenguajes OO imperativos extremadamente flexibles. En el caso de Haskell, las cosas serían mucho más difíciles, supongo.

Depende solo de las primitivas gráficas más básicas , luego construya sobre eso. OpenGL es bueno, pero incluso algo más simple (solo en 2D, por ejemplo, SDL) también funcionaría bien. Esto le dará la máxima flexibilidad y máxima portabilidad. Consulte Smalltalk / Morphic, Java / Swing, TCL / Tk.

Hágalo conceptualmente pequeño. Las GUI son tan difíciles como son, no es necesario agregar otro Everest para escalar. Haskell, espero, puede ayudar a que la cosa sea compacta y modular.

Para obtener puntos de bonificación, hágalo personalizable. Como mínimo, sepa cómo aplicar los colores del sistema (y solo los colores del sistema) para pintar todo su repertorio de controles, de modo que una aplicación creada con este kit de herramientas. no es una monstruosidad Como máximo, sepa cómo hacer que Win32 / Gtk / Qt / Cocoa dibuje sus controles para que se vean completamente nativos. La capacidad básica de la piel es simple y lógica; lograr un aspecto nativo completo es bastante difícil.

También, ejecute rootless y deje la administración de ventanas al sistema gráfico subyacente - X, Windows, lo que sea. No hacerlo pondrá a prueba la cordura de los usuarios y dificultará drásticamente la adopción.

Como es habitual, 'haga que las cosas simples sean simples y complejas posibles' + 'evite el tarpit de Turing donde todo es posible, pero nada de interés es simple' + 'lo más simple posible pero no más simple'.

El nombre es lo menos importante. De todos los kits de herramientas GUI populares, solo Qt tiene un nombre inteligente. Varios proyectos populares cambiaron de nombre, incluso en vuelo (Firefox, née Firebird). Ten algo que nombrar, y tú lo nombrarás.

¡Buena suerte!

    
respondido por el 9000 02.04.2011 - 00:56
1

Después de hablar entre todos los estudiantes involucrados y de darle suficiente tiempo a esta pregunta para generar interés, creo que hemos llegado a un consenso sobre algunas de las preguntas clave en mi publicación original.

  

¿A qué nivel de abstracción debería esforzarse nuestra biblioteca? El Wiki de Haskell parece indicar claramente que se preferiría una biblioteca de GUI de nivel medio; sin embargo, una biblioteca de alto nivel aún sería bienvenida.

Decidimos apuntar a una biblioteca de nivel medio según la sugerencia de Haskell Wiki.

  

¿Sobre qué debería construirse nuestra biblioteca? (Ej. OpenGL)

Elegimos OpenGL debido a su popularidad y soporte. Usaremos los GLUT o GLFW proyectos de envoltorios Haskell como base.

  

¿Qué biblioteca de GUI existente le gustaría ver en nuestra biblioteca (si existe) y por qué? (Por ejemplo, PyGame, Morphic, Swing, etc.)

Elegimos a Morphic después de un considerable debate entre él y PyGame. No consideramos QT o GTK ya que ambos ya tienen uno o más proyectos de la biblioteca Haskell en desarrollo activo .

  

¿Qué nombre inteligente le darías a esta biblioteca imaginaria? (Por ejemplo, HOT - Haskell Opengl Toolkit; HAWT - Haskell Advanced Windowing Toolkit)

Esto todavía está en debate. Hemos decidido no considerar HAWT y, en cambio, estamos considerando:

  • HOT - Haskell Opengl Toolkit
  • HOG - Haskell Opengl Graphics (¡Haga que su proyecto funcione con HOG!)
  • Schön
respondido por el Bface 01.04.2011 - 16:02

Lea otras preguntas en las etiquetas