Ich suche nach einer Bibliothek, um eine GUI auf GLFW und OpenGL zu schreiben. Ich mache das, weil ich mit den üblichen UI-Bibliotheksbindungen, die ich für zu wichtig halte, unzufrieden bin, und außerdem möchte ich das Erscheinungsbild meiner Benutzeroberflächen genau steuern. Ich hätte gerne einen deklarativen Ansatz zur Definition von UIs. Ich experimentiere mit reaktiven Bananen (und vorübergehend reaktiv-Bananen-wx), um zu sehen, ob es meine Bedürfnisse erfüllt. Ich habe ein Problem mit rekursiven Widgets zu definieren. Hier ist mein einfacher Testfall:
Das erste und das dritte Widget haben eine rekursive Beziehung. Das erste Widget ist intuitiv ein stepper eines union von Events, die von den beiden Buttons gespeist werden. Der Reset-Knopf ist jedoch ein fmap des Zählers und der Ereignisstrom beruht auf dem Reset-Knopf! Was ist zu tun?
Abgesehen von dieser Frage habe ich Bedenken bezüglich der Ereignisbehandlung: Da ich den Geräteein- und -eingabefokus innerhalb meines Codes handhaben möchte, anstatt mich auf ein Framework zu verlassen, sehe ich Schwierigkeiten bei der korrekten Verteilung von Ereignissen auf skalierbare Weise. Idealerweise würde ich eine data definieren, die die hierarchische Struktur eines Widgets kapselt, eine Möglichkeit, Ereignisrückrufe zwischen den Elementen zu installieren, und dann eine Funktion schreiben, die diese Datenstruktur durchläuft, um die Geräteeingabeverarbeitung und grafische Ausgabe zu definieren. Ich bin mir nicht sicher, wie ich einen Event-Stream aufnehmen und ihn so einfach aufteilen kann, wie Event-Streams zusammengeführt werden können.
Rekursion ist erlaubt, solange es sich um eine gegenseitige Rekursion zwischen einem Behavior und einem Event handelt. Das Schöne an Behavior s ist, dass das Sampling zum Zeitpunkt der Aktualisierung den alten Wert zurückgibt.
Zum Beispiel kann Ihr Beispiel wie folgt ausgedrückt werden
%Vor%Siehe auch die Frage "Können reaktive Bananen in der Netzwerk? "
Wie bei Ihrer zweiten Frage scheinen Sie nach der Funktion filterE und ihren Cousins filterApply und whenE ?
Was Ihr Gesamtziel anbelangt, denke ich, dass es ziemlich ehrgeizig ist. Aus den wenigen Erfahrungen, die ich bisher gemacht habe, scheint mir, dass die Bindung an einen bestehenden Rahmen sich ganz anders anhört als die Schaffung eines "Clean-State" -Rahmens in FRP. Höchstwahrscheinlich gibt es noch einige unentdeckte (aber aufregende!) Abstraktionen, die dort lauern. Ich habe einmal eine Anwendung namens BlackBoard geschrieben, die eine nette Abstraktion über zeitveränderliche Zeichnungen enthält.
Wenn Ihnen jedoch das Ergebnis wichtiger ist als das Abenteuer, würde ich einen konservativen Ansatz empfehlen: Erstellen Sie das GUI-Toolkit in einem imperativen Stil und haken Sie zusätzlich reactive-banana ein, um die Vorteile von FRP zu nutzen. p>
Falls Sie nur eine any GUI wünschen, konzentriere ich mich derzeit auf den Webbrowser als GUI. Hier einige vorbereitende Experimente mit Ji . Der Hauptvorteil gegenüber wxHaskell besteht darin, dass es viel einfacher ist, zum Laufen zu kommen, und alle API-Design-Bemühungen werden einem sehr breiten Publikum zugute kommen.
Tags und Links haskell user-interface frp reactive-banana