Suggerimenti per una libreria della GUI in Haskell [chiuso]

Naviga le tue risposte
14

Come Haskell Wiki stesso afferma :

There is a large number of GUI libraries for Haskell. Unfortunately there is no standard one and all are more or less incomplete. In general, low-level veneers are going well, but they are low level. High-level abstractions are pretty experimental. There is a need for a supported medium-level GUI library.

Un professore del mio college mi ha chiesto e tre altri laureati in informatica per prendere in considerazione la possibilità di lavorare su una libreria GUI per Haskell. La sua idea iniziale per il progetto era di scrivere uno strato su OpenGL che riproducesse la libreria morfica trovata in Smalltalk ; tuttavia, questo è solo un suggerimento e altri sistemi meritano sicuramente attenzione.

Questo ci porta alla domanda vera e multiparte.

  1. Per quale livello di astrazione dovrebbe mirare la nostra biblioteca? Haskell Wiki sembra indicare chiaramente che una libreria GUI di livello medio sarebbe preferibile; tuttavia, una libreria di alto livello sarebbe ancora ben accetta.
  2. Su cosa dovrebbe essere costruita la nostra biblioteca? (Es. OpenGL)
  3. Quale libreria della GUI esistente ti piacerebbe vedere la nostra libreria imitare (se esiste) e perché? (Es. PyGame, Morphic, Swing, ecc.)
  4. Quali funzioni vorresti vedere implementare o evitare la nostra libreria? Ad esempio, le brave persone di Gnome potrebbero obiettare che il pulsante minimizza non è necessario.
  5. Hai suggerimenti generali?
  6. Quale nome intelligente daresti a questa libreria immaginaria? (Es. HOT - Haskell Opengl Toolkit; HAWT - Haskell Advanced Windowing Toolkit)
posta Bface 21.03.2011 - 02:19
fonte

2 risposte

7

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

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

Dipende solo dalle primitive grafiche di base , quindi costruisci su questo. OpenGL è bello, ma anche qualcosa di più semplice (solo 2D, ad esempio SDL) andrebbe bene. Ciò ti darà la massima flessibilità e portabilità massima. Vedi Smalltalk / Morphic, Java / Swing, TCL / Tk.

Rendilo concettualmente piccolo. Le GUI sono difficili così come sono, non c'è bisogno di aggiungere un altro Everest per arrampicarsi. Spero che Haskell possa contribuire a rendere la cosa compatta e modulare.

Per i punti bonus, rendilo personalizzabile. Come minimo, sai come applicare i colori di sistema (e solo i colori di sistema) per dipingere l'intero repertorio di controlli, in modo che un'app creata con questo toolkit non è un pugno nell'occhio Al massimo, sappi come rendere Win32 / Gtk / Qt / Cocoa disegnare i tuoi controlli in modo che sembrino completamente nativi. La skinnability di base è semplice e logica; raggiungere un look nativo completo è piuttosto difficile.

Inoltre, per favore esegui rootless e lascia la gestione delle finestre al sistema grafico sottostante - X, Windows, qualunque sia. Non farlo in tal modo metterà alla prova la sanità mentale degli utenti e ostacolerà drasticamente l'adozione.

Come al solito, 'rendi semplici le cose semplici e complesse possibili' + 'evita il cratere di Turing dove tutto è possibile ma niente di interessante è semplice' + 'rendere il più semplice possibile ma non più semplice'.

Il nome è la cosa meno importante. Di tutti i popolari toolkit GUI, solo Qt ha un nome in qualche modo intelligente. Un certo numero di progetti popolari ha cambiato nome, anche in volo (Firefox, née Firebird). Hai qualcosa da nominare e lo nominerai.

Buona fortuna!

    
risposta data 02.04.2011 - 00:56
fonte
1

Dopo aver parlato con tutti gli studenti coinvolti e aver dato a questa domanda un tempo sufficiente per generare interesse, credo che abbiamo raggiunto un consenso su alcune delle domande chiave del mio post originale.

For what level of abstraction should our library strive? The Haskell Wiki seems to indicate strongly that a medium-level GUI library would be preferred; however, a high-level library would still be welcome.

Abbiamo deciso di mirare a una libreria di livello medio secondo il suggerimento di Haskell Wiki.

Upon what should our library be built? (Ex. OpenGL)

Abbiamo scelto OpenGL per la sua popolarità e il suo supporto. Utilizzeremo come base i progetti GLUT o GLFW Haskell wrapper.

What existing GUI library would you like to see our library mimic (if any) and why? (Ex. PyGame, Morphic, Swing, etc)

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

What clever name would you give this imaginary library? (Ex. HOT - Haskell Opengl Toolkit; HAWT - Haskell Advanced Windowing Toolkit)

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

  • HOT - Haskell Opengl Toolkit
  • HOG - Haskell Opengl Graphics (Crea il tuo progetto alimentato da HOG!)
  • Schön
risposta data 01.04.2011 - 16:02
fonte

Leggi altre domande sui tag

Le università senza scopo di lucro che offrono corsi di laurea in informatica in linea? [chiuso] È un odore di codice se si crea frequentemente un oggetto solo per chiamare un metodo su di esso