Suggerimenti per una libreria GUI in Haskell [chiuso]

Come afferma lo stesso Haskell Wiki :

Esiste un gran numero di librerie GUI per Haskell. Purtroppo non ce n'è uno standard e tutti sono più o meno incompleti. In generale, le faccette di basso livello stanno andando bene, ma sono di basso livello. Le astrazioni di alto livello sono piuttosto sperimentali. È necessaria una libreria GUI di medio livello supportata.

Un professore del mio college ha chiesto a me e ad altri tre specialisti di informatica di prendere in considerazione l'idea di lavorare in una biblioteca della GUI per Haskell. La sua idea iniziale per il progetto era quella di scrivere uno strato sopra OpenGL che imitasse la libreria morfica trovata in Smalltalk ; tuttavia, questo è solo un suggerimento e altri sistemi meritano sicuramente di essere presi in considerazione.

Questo ci porta alla vera domanda multi-parte.

1. Per quale livello di astrazione dovrebbe impegnarsi la nostra biblioteca? Il Wiki di Haskell sembra indicare fortemente che sarebbe preferibile una libreria GUI di medio livello; tuttavia, una biblioteca di alto livello sarebbe comunque benvenuta.
2. Su cosa dovrebbe essere costruita la nostra biblioteca? (Es. OpenGL)
3. Quale libreria GUI esistente vorresti vedere imitare la nostra libreria (se presente) e perché? (Es. PyGame, Morphic, Swing, ecc.)
4. Quali funzionalità vorresti che la nostra libreria implementasse o evitasse? Ad esempio, le brave persone di Gnome potrebbero obiettare che il pulsante minimizza non è necessario.
5. Hai qualche suggerimento generale?
6. Quale nome intelligente daresti a questa biblioteca immaginaria? (Es. HOT - Haskell Opengl Toolkit; HAWT - Haskell Advanced Windowing Toolkit)

Mi piacerebbe vedere una biblioteca elegante e semplice da usare con Haskell. Il resto sono dettagli tecnici che dovrebbero servire a questo scopo, non ridefinirlo. Quindi i miei $ 0,02.

Non basarlo su un toolkit esistente , come Qt o GTK o FLTK o ... - questo ti limiterà notevolmente e probabilmente ti darà molto più dolore che profitto. PyQt è, erm, abbastanza divertente e inventato, e sia Python che C ++ sono linguaggi OO imperativi estremamente flessibili. Nel caso di Haskell, le cose sarebbero molto più ruvide, suppongo.

Dipendi solo dalle primitive grafiche più elementari , quindi costruisci su quello. OpenGL è carino, ma anche qualcosa di più semplice (solo 2D, ad esempio SDL) farebbe bene. Questo ti darà la massima flessibilità e la massima portabilità. Vedi Smalltalk / Morphic, Java / Swing, TCL / Tk.

Rendilo concettualmente piccolo. Le GUI sono difficili come sono, non è necessario aggiungere un altro Everest per arrampicarsi. Spero che Haskell possa aiutare a rendere la cosa compatta e modulare.

Per i punti bonus, rendilo personalizzabile. Come minimo, sapere come applicare i colori di sistema (e solo i colori di sistema) per dipingere l'intero repertorio di controlli, in modo che un'app costruita con questo toolkit non sia un problema. Come massimo, sapere come far disegnare Win32 / Gtk / Qt / Cocoa ai tuoi controlli in modo che appaiano completamente nativi. La skinnability di base è semplice e logica; ottenere un look nativo completo è piuttosto difficile.

Inoltre, esegui rootless e lascia la gestione delle finestre al sistema grafico sottostante - X, Windows, qualunque cosa. Non farlo metterà in discussione la sanità mentale degli utenti e ostacolerà drasticamente l'adozione.

Come al solito, "rendi semplici le cose semplici e complesse" + "evita il tarpit di Turing dove tutto è possibile ma nulla di interessante è semplice" + "rendilo il più semplice possibile ma non più semplice".

Il nome è la cosa meno importante. Di tutti i popolari toolkit della GUI, solo Qt ha un nome in qualche modo intelligente. Numerosi progetti popolari hanno cambiato nome, anche durante il volo (Firefox, nata Firebird). Hai qualcosa da nominare e lo nominerai.

In bocca al lupo!

Dopo aver parlato tra tutti gli studenti coinvolti e aver dato a questa domanda tempo sufficiente per generare interesse, credo che siamo giunti a un consenso su alcune delle domande chiave nel mio post originale.

Per quale livello di astrazione dovrebbe impegnarsi la nostra biblioteca? Il Wiki di Haskell sembra indicare fortemente che sarebbe preferibile una libreria GUI di medio livello; tuttavia, una biblioteca di alto livello sarebbe comunque benvenuta.

Abbiamo deciso di puntare a una biblioteca di medio livello su suggerimento del Wiki di Haskell.

Su cosa dovrebbe essere costruita la nostra biblioteca? (Es. OpenGL)

Abbiamo scelto OpenGL per la sua popolarità e supporto. Saremo utilizzando il GLUT o GLFW Haskell involucro progetti come base.

Quale libreria GUI esistente vorresti vedere imitare la nostra libreria (se presente) e perché? (Es. PyGame, Morphic, Swing, ecc.)

Abbiamo scelto Morphic dopo un considerevole dibattito tra esso e PyGame. Non abbiamo preso in considerazione QT o GTK poiché entrambi hanno già uno o più progetti di librerie Haskell in sviluppo attivo .

Quale nome intelligente daresti a questa biblioteca immaginaria? (Es. HOT - Haskell Opengl Toolkit; HAWT - Haskell Advanced Windowing Toolkit)

Questo è ancora in discussione. Abbiamo deciso di non prendere in considerazione HAWT e invece stiamo guardando:

• CALDO - Haskell Opengl Toolkit
• HOG - Grafica Haskell Opengl (Rendi il tuo progetto basato su HOG!)
• Schön