Hello, I'm trying to write simple GTK2hs adapter using new reactive library. However, I've ran into some issues there: 1. All of the adapters i've seen come with static "primitive signals", like FRP.Reactive.GLUT.Adapter.UI. But this doesn't seem to be applicable to UIs like "UI loaded from glade file" because it's impossible to create all signals in advance -- you should be able to create them with functions like: mkButton :: Glade -> String -> IO (Event ()) but that doesn't seem to fit well into FRP.Reactive.LegacyAdapters interface. 2. Is stacking of multiple adapters possible? In my view it's essential feature for many applications, GUI network clients, for example. Best wishes and thanks in advance, -- pierre
Hi Pierre,
1. I'm starting to work on a Reactive/wxHaskell for use with Phooey, GuiTV,
and Eros. I'd love to see a gtk2hs adapter available, and I imagine it
would be done similarly to wxHaskell's.
2. The whole adapter interface is very recent and will likely evolve. I'm a
big fan of compositionality, so composing adapters interests me.
Regards, - Conal
On Mon, Nov 10, 2008 at 10:04 AM, pierre
Hello,
I'm trying to write simple GTK2hs adapter using new reactive library.
However, I've ran into some issues there:
1. All of the adapters i've seen come with static "primitive signals", like FRP.Reactive.GLUT.Adapter.UI. But this doesn't seem to be applicable to UIs like "UI loaded from glade file" because it's impossible to create all signals in advance -- you should be able to create them with functions like:
mkButton :: Glade -> String -> IO (Event ())
but that doesn't seem to fit well into FRP.Reactive.LegacyAdapters interface.
2. Is stacking of multiple adapters possible? In my view it's essential feature for many applications, GUI network clients, for example.
Best wishes and thanks in advance, -- pierre _______________________________________________ Reactive mailing list Reactive@haskell.org http://www.haskell.org/mailman/listinfo/reactive
On Mon, Nov 10, 2008 at 1:04 PM, pierre
Hello,
I'm trying to write simple GTK2hs adapter using new reactive library.
However, I've ran into some issues there:
1. All of the adapters i've seen come with static "primitive signals", like FRP.Reactive.GLUT.Adapter.UI. But this doesn't seem to be applicable to UIs like "UI loaded from glade file" because it's impossible to create all signals in advance -- you should be able to create them with functions like:
mkButton :: Glade -> String -> IO (Event ())
but that doesn't seem to fit well into FRP.Reactive.LegacyAdapters
interface. Hrm, I'm having trouble understanding the situation here. What would the context around mkButton look like? Are you looking for something like the following? data WidgetHeiarchy = Button Identifier (Event ()) | Frame Identifyer [WidgetHeiarchy] | ... data WidgetHeiarchyStates = SButton Color | ... adapt :: Glade -> (WidgetHeiarchy -> Behavior WidgetHeiarchyStates ) -> IO()
2. Is stacking of multiple adapters possible? In my view it's essential feature for many applications, GUI network clients, for example.
I agree that it's an essential feature. If your event generators and behavior sinks can all run on separate threads, you're good to go. The situation gets complicated when event generators or behavior sinks all require blocking on the main thread. We had some simple legacy adapters at one point (forkE forkB), but I'm not sure if they're still in the source somewhere. -- David Sankel
On Mon, Nov 10, 2008 at 05:55:45PM -0500, David Sankel wrote:
Hrm, I'm having trouble understanding the situation here. What would the context around mkButton look like? Are you looking for something like the following?
data WidgetHeiarchy = Button Identifier (Event ()) | Frame Identifyer [WidgetHeiarchy] | ...
data WidgetHeiarchyStates = SButton Color | ...
adapt :: Glade -> (WidgetHeiarchy -> Behavior WidgetHeiarchyStates ) -> IO()
Wouldn't enomous size of WidgetHeiarchy and WidgetHeiarchyStates be problematic? GTK2 has an enormous number of events and states so (imho) it's not practical to try to encode them all (and create an event for each possible callback). In case of "partial encoding", i don't know how this could be extensible.
2. Is stacking of multiple adapters possible? In my view it's essential feature for many applications, GUI network clients, for example.
I agree that it's an essential feature. If your event generators and behavior sinks can all run on separate threads, you're good to go. The situation gets complicated when event generators or behavior sinks all require blocking on the main thread. We had some simple legacy adapters at one point (forkE forkB), but I'm not sure if they're still in the source somewhere. -- David Sankel
-- pierre
On Tue, Nov 11, 2008 at 11:26 AM, pierre
On Mon, Nov 10, 2008 at 05:55:45PM -0500, David Sankel wrote:
Hrm, I'm having trouble understanding the situation here. What would the context around mkButton look like? Are you looking for something like the following?
data WidgetHeiarchy = Button Identifier (Event ()) | Frame Identifyer [WidgetHeiarchy] | ...
data WidgetHeiarchyStates = SButton Color | ...
adapt :: Glade -> (WidgetHeiarchy -> Behavior WidgetHeiarchyStates ) ->
IO()
Wouldn't enomous size of WidgetHeiarchy and WidgetHeiarchyStates be problematic?
Is it just as enormous, asymptotically, on the C side of things? (sorry for the double send) -- David Sankel Sankel Software
participants (3)
-
Conal Elliott -
David Sankel -
pierre