Quali sono i meriti relativi wxHaskell e Gtk2HS?

Question

Che è meglio per lo sviluppo di applicazioni GUI con Haskell, wxWidgets (via wxHaskell ) o GTK (via < a href = "http://www.haskell.org/gtk2hs/" rel = "noreferrer"> Gtk2HS )?

Quali sono i pro ei contro di ciascuno? Ha variano a seconda di quale piattaforma ci si rivolge (vorrei in primo luogo essere al lavoro su OS X, ma vorrei i miei programmi per lavorare su Linux e Windows troppo)?

Answer 1

[Disclaimer: Sono un manutentore wxHaskell]

Entrambi sono attacchi GUI stabili e abbastanza completo, e si poteva scegliere sia per la maggior parte dei progetti con fiducia. Entrambi hanno un certo grado di 'livello superiore' binding Haskell, ma in entrambi i casi sarà necessario far cadere in piuttosto imperativo codifica 'C' stile di fare le cose. La mia impressione è che wxHaskell permette di trascorrere un po 'di tempo nei collegamenti a livello più alto, ma non ho fatto molto GTK2HS, e in ogni caso, è sicuramente trovate a lavorare sul lato sottile del wrapper per entrambe le biblioteche - e credo che la programmazione generale 'complessità' è simile in entrambi i casi.

Quindi, diamo la funzionalità di base come un dato di fatto e concentrarsi sulle differenze. Si prega di notare che sono davvero convinto che GTK2HS è un ottimo lavoro, e che sarà felice se si sceglie. La maggior parte di quello che dico qui di seguito è un introito personale sulle differenze, e perché ho scelto di lavorare su e con wxHaskell me stesso.

GTK2HS ha un team più grande lavoro su di esso, e viene rilasciato con maggiore regolarità. wxHaskell non viene aggiornato frequentemente, ma il core team è attivo, e ci sono correzioni regolari, ma con importanti nuove funzionalità che si aggiunge un po 'più lentamente di quanto vorremmo (che tutti noi abbiamo posti di lavoro al giorno).

wxHaskell dà il vero aspetto applicazione nativa su tutte le piattaforme supportate, fuori dalla scatola. GTK2HS è, naturalmente, nativo su Linux e ha un buon tema nativo su Windows (vale a dire abbastanza buono per soddisfare tutti, ma pedanti ...), ma ha GTK guardare e sentire su OSX, e dipende da avere installato X11. Credo che 'native' libreria GTK un OSX è in fase di sviluppo, ma è considerato relativamente immaturo. Una volta che questo è stabile, GTK2HS dovrebbero essere in grado di beneficiare facilmente dalla stessa look 'parzialmente nativo' e si sentono (ad esempio, GTK OSX screenshot ).

wxHaskell è probabilmente un po 'più facile da costruire, se non siete su Linux (GTK2HS è probabile più facile se siete Linux ospitato), ma entrambi sono abbastanza complesso da costruire, ad essere onesti, in quanto vi sono un numero significativo di dipendenze in entrambi i casi.

E 'un po' più facile (IMHO) per distribuire applicazioni basate su wxHaskell, semplicemente perché ha un minor numero di dipendenze di librerie. Ho distribuire le applicazioni utilizzando principalmente InnoSetup su Windows, e come App bundle su OSX. Vorrei ammettere che solo una piccola quantità di lavoro supplementare, lo stesso potrebbe essere fatto con GTK2HS, quindi questo è probabilmente l'argomento più debole a favore del wxHaskell.

E 'mia opinione personale che wxHaskell è amichevole per closed source sviluppi (ad esempio commerciali). Questo è, ovviamente, oggetto di interminabili guerre di fiamma, quindi mi limito a dire che wxHaskell è sotto il rel="noreferrer"> che permette in modo inequivocabile per lo sviluppo closed source. GTK2HS è LGPL, quindi avrai bisogno di chiedere il vostro avvocato - anche se devo chiarire che molte persone e aziende hanno concluso che LGPL è compatibile con lo sviluppo commerciale; gli avvocati presso l'azienda per cui lavoro hanno concluso che non è opportuno per i nostri progetti.

Credo che se Linux era la mia piattaforma di sviluppo e la consegna principale, probabilmente sarei uso GTK2HS. Non si tratta, però:. Consegno principalmente a Windows con occasionali OSX, e penso che wxHaskell risulta più simile a queste piattaforme, anche se entrambe le opzioni supportano tutte e tre le piattaforme

Spero che questo vi aiuterà con la vostra scelta.

Answer 2

Una considerazione è che attualmente è leggermente più facile ottenere wxHaskell per lavorare nativamente su Mac OS X. GTK2HS dipende da GTK, che ha un'implementazione utilizzando i widget nativi su Mac OS X, ma che l'attuazione non è così facilmente costruito come l'attuazione wxWidgets per Mac OS X è.

Pertanto, se si vuole sviluppare il codice per eseguire senza X11.app, attualmente siete un po 'meglio con wxHaskell.

Si noti tuttavia che questo sta cambiando in fretta: http://www.haskell.org/haskellwiki/Gtk2Hs#Using_the_GTK.2B_OS_X_Framework mostra come utilizzare GTK2HS con nativo GTK + su Mac OS X.

Un vantaggio di GTK2HS è il supporto GLADE, rendendo lo sviluppo di semplice interfaccia utente molto veloce. I combinatori di livello superiore a wxHaskell mitigare la maggior parte di tale vantaggio, ma richiedono una più profonda comprensione di come si desidera l'interfaccia a guardare e si comportano, e quindi sono più difficili da utilizzare in maniera esplorativa.

Answer 3

Ho informazioni abbastanza incomplete, ma poiché avete ancora risposto a domande, forse informazioni incomplete è meglio di niente.

La domanda da porsi è questa: è il toolkit solo un wrapper funzionalità C-like, o c'è un ulteriore livello che dà il toolkit più "nativa Haskell-like" API? Quando wxHaskell stato annunciato al workshop Haskell, lo sviluppo delle API native Haskell sembrava molto promettente, ma era ancora incompleta. Sembra come se l'API "Haskellized" per wxHaskell è ancora in lavorazione, mentre il progetto Gtk2Hs non menziona questo problema a tutti. Per questo motivo vi consiglio wxHaskell.

Answer 4

Personalmente vorrei guardare in una sorta di pacchetto di reattivo / estensione. Sembra di sedersi con il paradigma molto molto più vicino. Invece di specificare la tua roba grafica imperativamente, si può fare in modo dichiarativo. Esempio (non rappresentativo di una determinata lingua o implementazione):

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 ez verrà aggiornato automaticamente ogni volta x ed y cambiamento.

Si potrebbe quindi avere una certa logica da qualche parte che sembra qualcosa di simile:

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

Questo è tutto molto sfocata però. Basta guardare in alcune interfacce reale reattivi