Co jest lepsze dla tworzenia aplikacji GUI z Haskell, wxWidgets (przez wxHaskell) lub GTK (przez Gtk2HS)?Jakie są względne zalety wxHaskell i Gtk2HS?
Jakie są plusy i minusy każdego? Czy różni się w zależności od platformy, na którą kierujesz (przede wszystkim pracowałbym na OS X, ale chciałbym, aby moje programy działały również na Linuksie i Windowsie)?
[Zastrzeżenie: Jestem opiekunem wxHaskell]
Oba są dość stabilne i kompletne Wiązania GUI, i można wybrać albo dla większości projektów z ufnością. Oba mają pewien stopień powiązań Haskella "wyższego poziomu", ale w obu przypadkach będziesz musiał wkroczyć w raczej bezwzględne kodowanie w stylu "C", aby wszystko załatwić. Mam wrażenie, że wxHaskell pozwala ci spędzić trochę więcej czasu w wiązaniach wyższego poziomu, ale nie zrobiłem zbyt wiele GTK2HS iw każdym razie na pewno znalazłeś pracę nad cienkim końcem opakowania dla obu bibliotek - i myślę, że ogólna "złożoność" programowania jest podobna w obu przypadkach.
Przyjmijmy więc podstawową funkcjonalność jako podaną i skoncentrujmy się na różnicach. Należy pamiętać, że naprawdę wierzę, że GTK2HS jest świetnym dziełem, i że będziesz szczęśliwy, jeśli go wybierzesz. Większość z tego, co poniżej mówię, to osobiste podejście do różnic i to, dlaczego sam decyduję się pracować i z wxHaskell.
GTK2HS ma większy zespół nad nim pracujący i jest wydawany bardziej regularnie. wxHaskell nie jest aktualizowany tak często, ale podstawowy zespół jest aktywny, i istnieją regularne poprawki błędów, ale z większą nowością dodawana jest raczej wolniej niż byśmy chcieli (wszyscy mamy prace dzienne).
wxHaskell daje prawdziwy, macierzysty wygląd aplikacji na wszystkich obsługiwanych platformach po wyjęciu z pudełka. GTK2HS jest oczywiście rodzimą wersją systemu Linux i ma bardzo dobry natywny motyw w systemie Windows (tj. Wystarczająco dobry, aby zadowolić wszystkich oprócz pedantów ...), ale ma wygląd i działanie GTK na OSX i zależy od zainstalowania X11. Uważam, że "natywna" biblioteka GTK OSX jest w fazie rozwoju, ale jest uważana za względnie niedojrzałą. Gdy jest stabilny, GTK2HS powinien móc z łatwością czerpać korzyści z tego samego "częściowo natywnego" wyglądu i odczucia (na przykład GTK OSX screenshot).
wxHaskell jest prawdopodobnie trochę łatwiejszy do zbudowania, jeśli nie jesteś na Linuksie (GTK2HS jest prawdopodobnie łatwiejszy, jeśli masz hostowany Linux), ale oba są dość skomplikowane do zbudowania, szczerze mówiąc, ponieważ istnieje znaczna liczba zależności w obu przypadkach.
Jest nieco łatwiej (IMHO) rozpowszechniać aplikacje na podstawie wxHaskell, po prostu dlatego, że ma mniej zależności bibliotek. Rozprowadzam aplikacje wykorzystujące głównie InnoSetup w Windows oraz jako pakiety App w OSX. Przyznam, że przy niewielkiej ilości dodatkowej pracy, to samo można zrobić z GTK2HS, więc jest to prawdopodobnie najsłabszy argument na korzyść wxHaskell.
To moja osobista opinia, że wxHaskell jest bardziej przyjazny dla zamkniętych źródeł (np. Komercyjnych). Jest to oczywiście przedmiotem niekończących się wojen płomieniowych, więc powiem tylko, że wxHaskell jest pod wxWidgets license, co jednoznacznie pozwala na rozwój zamkniętego źródła. GTK2HS to LGPL, więc będziesz musiał zapytać swojego prawnika - choć muszę wyjaśnić, że wiele osób i firm uznało, że LGPL jest kompatybilny z komercyjnym rozwojem; prawnicy w firmie, dla której pracuję, stwierdzili, że jest ona nieodpowiednia dla naszych projektów.
Myślę, że jeśli Linux byłby moją główną platformą rozwoju i dostarczania, prawdopodobnie użyłbym GTK2HS. Nie jest to jednak: dostarczam głównie do Windowsa z okazjonalnym OSX i myślę, że wxHaskell lepiej pasuje do tych platform, chociaż obie opcje obsługują wszystkie trzy platformy.
Mam nadzieję, że pomoże ci to w dokonaniu wyboru.
Mam dość niekompletne informacje, ale ponieważ nie masz jeszcze odpowiedzi, może niepełne informacje są lepsze niż żadne.
Pytanie, które należy zadać, brzmi: czy zestaw narzędzi jest jedynie opakowaniem funkcjonalności podobnej do języka C, czy istnieje dodatkowa warstwa, która nadaje zestawowi narzędzi bardziej "natywny interfejs podobny do Haskella"? Kiedy wxHaskell został po raz pierwszy ogłoszony w warsztacie Haskella, rozwój natywnego interfejsu API Haskell wyglądał wyjątkowo obiecująco, ale wciąż był niekompletny. Wygląda na to, że API "Haskellized" dla wxHaskell wciąż jest opracowywane, podczas gdy projekt Gtk2Hs w ogóle nie wspomina o tym problemie. Z tego powodu polecam wxHaskell.
Rozważa się, że obecnie nieco łatwiej jest uzyskać wxHaskell do pracy natywnie na Mac OS X. GTK2HS zależy od GTK, który ma implementację z natywnymi widżetami na Mac OS X, ale ta implementacja nie jest tak łatwo zbudowana jako implementacja wxWidgets dla Mac OS X.
Dlatego jeśli chcesz opracować kod do uruchomienia bez X11.app, w tej chwili jesteś nieco lepiej z wxHaskell.
jednak pamiętać, że jest to szybko zmienia: http://www.haskell.org/haskellwiki/Gtk2Hs#Using_the_GTK.2B_OS_X_Framework pokazuje jak używać GTK2HS z natywnym GTK + na Mac OS X.
Jedną z zalet GTK2HS jest obsługa polana, czyniąc rozwój prostym interfejsie bardzo szybki. Kombinatory wyższego poziomu w wxHaskell zmniejszają większość tej przewagi, ale wymagają głębszego zrozumienia, jak interfejs ma wyglądać i jak się zachowują, a zatem są trudniejsze do wykorzystania w sposób eksploracyjny.
Osobiście zajrzałbym do jakiegoś rodzaju reaktywnego pakietu/rozszerzenia. Wydaje się, że jest on znacznie bardziej zbliżony do tego paradygmatu. Zamiast bezbłędnie określać swoje elementy graficzne, możesz to zrobić w sposób deklaratywny. Przykład (nie przedstawiciel danym języku lub realizacji):
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 i Z będą automatycznie aktualizowane za każdym razem xiy zmiany.
Można wtedy mieć jakąś logikę gdzieś, który wygląda mniej więcej tak:
if buttonclicked then <do something> else <do something else>
To wszystko jest bardzo niewyraźny choć. Wystarczy spojrzeć na kilka reaktywnych interfejsów