Am Samstag, 14. Februar 2009 23:37 schrieb Roman Cheplyaka:

* Wolfgang Jeltsch [2009-02-14 17:19:09+0100]

...

Dear friends of Haskell and Functional Reactive Programming,

its my pleasure to announce the first official release of Grapefruit, a library for Functional Reactive Programming (FRP) with a focus on user interfaces.

With Grapefruit, you can implement reactive and interactive systems in a declarative style. User interfaces are described as networks of communicating widgets and windows. Communication is done via different kinds of signals which describe temporal behavior.

Greetings!

Does this version not support Codebreaker and CircuitingObjects examples shown on the wiki page? Or there's another reason why they are not included in the grapefruit-examples?

Sadly, both are not supported at the moment. The reasons are described under http://haskell.org/haskellwiki/Grapefruit#Versions:

Grapefruit underwent fundamental interface and implementation changes before this release. A version from before these changes is available as the “classic” version. In contrast to the released version, the classic version contains support for animated graphics, incrementally updating list signals and a restricted form of dynamic user interfaces (user interfaces whose widget structure may change). These features are expected to come back in future releases.

CircuitingObjects needs the graphics support (obviously) and Codebreaker needs at least incrementally updating list signals. I want to start hacking on these kind of signals today, so I hope that Codebreaker can soon run again. Maybe there is someone interested in helping me with the graphics support? There is already quite some stuff implemented (thanks to Matthias Reisner), it’s just that this is based on the classic interface of Grapefruit. Best wishes, Wolfgang

Am Dienstag, 17. Februar 2009 17:18 schrieben Sie:

I'm glad that FRP isn't still alive and kicking.

You are glad that FRP is *not* alive? Okay, this was a typo, wasn’t it? ;-)

I hope you will support wxHAskell in the near future. I tried wxFruit and I liked it, but it isn't complete and it is not in development. I tried GTK2HS, but it was too buggy (probably because of the Windows version of GTK+, Cairo was quite buggy to), so I switched to wxHaskell.

Well, I have no plans myself to create a wxHaskell UI backend, basically for one reason: wxWidgets tries to implement the same API using different native UI libs for getting native look and feel. However, when I last checked, it didn’t seem to do this very well. So I decided to implement the multi-toolkit feature directly in Grapefruit. If you have problems with Gtk2Hs on Windows, it might be better to write a Win32-based backend for Grapefruit instead of a wxWidgets-based one. What do you think about that? Best wishes, Wolfgang

Am Dienstag, 17. Februar 2009 19:36 schrieben Sie:

...

If you have problems with Gtk2Hs on Windows, it might be better to write a Win32-based backend for Grapefruit instead of a wxWidgets-based one. What do you think about that?

Win32-based backend would make more sense as it is one less layer to deal with. But how? Same thing with Mac.

A student of mine wrote a fully automatic binding generator for C++ libraries which also supports Qt extensions (signals and slots). (However, this guy still has to give me the code. :-/ ) One could do a similar thing for generating Win32 and Cocoa bindings. Then one could write Grapefruit UI backends based on these bindings. Best wishes, Wolfgang

When he gives you the code, could you let me know? I would really love to bind Open Scene Graph, but it's entirely C++ and that makes for a lot more difficult coding to say the least. On Wed, Feb 18, 2009 at 4:17 AM, Wolfgang Jeltsch wrote:

Am Dienstag, 17. Februar 2009 19:36 schrieben Sie:

...

...

If you have problems with Gtk2Hs on Windows, it might be better to write a Win32-based backend for Grapefruit instead of a wxWidgets-based one. What do you think about that?

Win32-based backend would make more sense as it is one less layer to deal with. But how? Same thing with Mac.

A student of mine wrote a fully automatic binding generator for C++ libraries which also supports Qt extensions (signals and slots). (However, this guy still has to give me the code. :-/ ) One could do a similar thing for generating Win32 and Cocoa bindings. Then one could write Grapefruit UI backends based on these bindings.

Best wishes, Wolfgang _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Hello Jeff, it’s been some time that we had the conversation below and I have to tell you the same thing I told Jamie in a haskell-cafe mail sent a few minutes ago: The student who wrote the Qt binding generator never managed to send me a final version of his code. At least, I was able to make him send me the current state. I don’t think he will improve this code anymore. If you want to have a look at the code, please visit http://haskell.org/haskellwiki/HQK and follow the link to the code and have a look at the building tips. In case you would like to improve the binding generator, I’d be happy to receive patches. :-) Sorry for these bad news. Best wishes, Wolfgang Am Mittwoch, 18. Februar 2009 15:42 schrieb Jeff Heard:

When he gives you the code, could you let me know? I would really love to bind Open Scene Graph, but it's entirely C++ and that makes for a lot more difficult coding to say the least.

On Wed, Feb 18, 2009 at 4:17 AM, Wolfgang Jeltsch

wrote:

...

Am Dienstag, 17. Februar 2009 19:36 schrieben Sie:

...

...

If you have problems with Gtk2Hs on Windows, it might be better to write a Win32-based backend for Grapefruit instead of a wxWidgets-based one. What do you think about that?

Win32-based backend would make more sense as it is one less layer to deal with. But how? Same thing with Mac.

A student of mine wrote a fully automatic binding generator for C++ libraries which also supports Qt extensions (signals and slots). (However, this guy still has to give me the code. :-/ ) One could do a similar thing for generating Win32 and Cocoa bindings. Then one could write Grapefruit UI backends based on these bindings.

Best wishes, Wolfgang _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe