Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Am Montag, 16. Februar 2009 15:27 schrieben Sie: On Mon, 16 Feb 2009, Wolfgang Jeltsch wrote: [redirecting to haskell-cafe] Am Sonntag, 15. Februar 2009 00:25 schrieben Sie: Hi Wolfgang, I was wondering if I can use FLTK as GUI backend for Grapefruit? This should be possible in principal. It just could be that my assumptions about how widgets are created and composed were too tight so that Grapefruit’s general interface doesn’t fit FLTK. In this case, please just tell me and I will try to make the interface more general. Ok, great I ll have to use them then I will see and know what improvement is needed. I believe for this to make it happen, I would have to output FLTK's C++ into C then create bindings for Haskell (via FFI). Is that doable or an quite tall order? Recently, a student of mine has written a program which generates a Haskell Qt binding fully automatically from Qt header files. The generated binding consists of three layers. The first layer is C++ code which reexports Qt’s functionality as a pure C interface. The C interface is ugly for humans and not type safe (because C doesn’t know classes). The second layer consists of a couple of FFI declarations. The third layer is Haskell code which provides a nice interface similar to the original C++ interface. I still have to get the source code of the binding generator from that student but I hope this will happen soon. I want to publish it then on the web. It hope that it is possible to reuse this binding generator for other C++ libraries. That would be very helpful, I ll be looking forward. Hello Jamie, it’s been quite some time that we had this discussion about writing a FLTK-based GUI backend for Grapefruit. I’m sorry that I have to tell you that the above-mentioned student never managed to send me a final version of this Qt binding generator. At least, I was able to make him send me the current state of his code. 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. :-) Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
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 g9ks1...@acme.softbase.org 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
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
Re[2]: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Hello Wolfgang, Wednesday, February 18, 2009, 12:17:16 PM, you wrote: 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. win32 api is, not c++, and for this purpose hsffig also exists -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
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 g9ks1...@acme.softbase.org 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Am Mittwoch, 18. Februar 2009 15:42 schrieben Sie: 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. Yes, I will let you know. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Am Montag, 16. Februar 2009 22:04 schrieben Sie: As for how I want Hieroglyph to work interactively, I think the easiest way is to react to the input data considered as a coherent whole. The semantic model for visualization is that a Visualization is a function from Data to Visual. Hmm, doesn’t this approach result in scalability problems? You always have to analyse the complete input data if a small part of it changes and you always have to update the complete picture. This is similar to the problems I see with Yampa-based UI approaches. However, you might be interested in things like incremental list signals which I’m (re-)implementing at the moment. To a large degree, the library user sees a time-varying list but internally the library takes care of not updating the whole list all the time but only the parts which actually change. The main problem I have, which is what I want FRP for, is that to consider the data as a coherent whole, the data have to be composable. I don’t really understand this. Could you explain this, please? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
On Sat, 14 Feb 2009 17:19:09 +0100, Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: If you have questions, applause or criticism, please get in touch with me. Wolfgang Jeltsch Principal Grapefruit developer I'm glad that FRP isn't still alive and kicking. 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. -- Regards, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
On Tue, 17 Feb 2009, Wolfgang Jeltsch wrote: 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? Win32-based backend would make more sense as it is one less layer to deal with. But how? Same thing with Mac. Jamie Best wishes, Wolfgang___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
[redirecting to haskell-cafe] Am Samstag, 14. Februar 2009 23:13 schrieben Sie: Great, does it run well on Windows and Mac platforms in addition to Linux platform which should run fine? Actually, I have no idea. ;-) Well, Grapefruit is a pure Haskell library without any own binding to C libraries or whatever. For GUI stuff, Grapefruit relies completely on Gtk2Hs. So if Gtk2Hs works, Grapefruit should work too. I just haven’t tested it so far. Earlier Grapefruit code was successfully executed on the Windows box of my co-developer. On the other hand, Grapefruit is designed to be implemented on top of different toolkits, although currently there is only the Gtk2Hs backend. So if you want to write a backend based on the Win32 API or Cocoa, this would be very welcome. :-) I am planning to create video phone software and I was looking for good GUI toolkit that supports FRP so it looks like it is right time to use Grapefruit :) This would be really great. Writing applications with Grapefruit gives me useful feedback and pressure for improvement. Note that currently the set of supported widgets is very low but this is likely to change during the next weeks and it should often be very easy to port Gtk2Hs widgets to Grapefruit. Thanks Jamie Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
[redirecting to haskell-cafe] Am Sonntag, 15. Februar 2009 00:25 schrieben Sie: Hi Wolfgang, I was wondering if I can use FLTK as GUI backend for Grapefruit? This should be possible in principal. It just could be that my assumptions about how widgets are created and composed were too tight so that Grapefruit’s general interface doesn’t fit FLTK. In this case, please just tell me and I will try to make the interface more general. I believe for this to make it happen, I would have to output FLTK's C++ into C then create bindings for Haskell (via FFI). Is that doable or an quite tall order? Recently, a student of mine has written a program which generates a Haskell Qt binding fully automatically from Qt header files. The generated binding consists of three layers. The first layer is C++ code which reexports Qt’s functionality as a pure C interface. The C interface is ugly for humans and not type safe (because C doesn’t know classes). The second layer consists of a couple of FFI declarations. The third layer is Haskell code which provides a nice interface similar to the original C++ interface. I still have to get the source code of the binding generator from that student but I hope this will happen soon. I want to publish it then on the web. It hope that it is possible to reuse this binding generator for other C++ libraries. Jamie Clark Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
[redirecting to haskell-cafe] Am Sonntag, 15. Februar 2009 00:26 schrieben Sie: One more thing, would Grapefruit work with files created by Glade (UI builder)? No, it won’t, I’m afraid. There is, for example, the principal problem that Glade is GTK+-specific (as far as I know) while Grapefruit shall have a toolkit-independent library interface. However, I don’t think it is such a good idea to support traditional GUI builders. These builders typically let you design a static interface but you have to code event handlers or similar stuff completely by hand and you have practically no support for dynamic user interfaces (user interfaces that change their structure). On the other hand, Grapefruit uses arrow notation for composing user interfaces so that the source code already reflects the visual appearence of the GUI to a certain degree. For example, you just list the widgets of a box and say what their input and output signals are. That said, I still think it might be a good idea to use a GUI builder together with Grapefruit. But such a builder should be specifically designed for Grapefruit, in my opinion. I already have some rough ideas in my mind about how such a builder could work. I’d want it to cover also the communication between the UI components (using signals) and maybe even dynamic user interfaces. If you are interested in my ideas, please ask. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Wolfgang == Wolfgang Jeltsch g9ks1...@acme.softbase.org writes: Wolfgang This would be really great. Writing applications with Wolfgang Grapefruit gives me useful feedback and pressure for Wolfgang improvement. Note that currently the set of supported Wolfgang widgets is very low but this is likely to change during Wolfgang the next weeks and it should often be very easy to port Wolfgang Gtk2Hs widgets to Grapefruit. So I have an application that I am developing. The UI module includes the following: import Graphics.UI.Gtk import Graphics.Rendering.Cairo import Graphics.Rendering.Cairo.SVG import Graphics.UI.Gtk.Gdk.EventM Can you tell from that list if i am likely to be able to rewrite it to use Grapefruit? -- Colin Adams Preston Lancashire ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
On Mon, 16 Feb 2009, Wolfgang Jeltsch wrote: [redirecting to haskell-cafe] Am Samstag, 14. Februar 2009 23:13 schrieben Sie: Great, does it run well on Windows and Mac platforms in addition to Linux platform which should run fine? Actually, I have no idea. ;-) Well, Grapefruit is a pure Haskell library without any own binding to C libraries or whatever. For GUI stuff, Grapefruit relies completely on Gtk2Hs. So if Gtk2Hs works, Grapefruit should work too. I just haven’t tested it so far. Earlier Grapefruit code was successfully executed on the Windows box of my co-developer. On the other hand, Grapefruit is designed to be implemented on top of different toolkits, although currently there is only the Gtk2Hs backend. So if you want to write a backend based on the Win32 API or Cocoa, this would be very welcome. :-) Great. Well thought out design :) Other possible backends would be FLTK, GLUI, XBMC/Boxee (for set-top box apps) as well Qt and wxWidgets. I guess backends using Win32 API/Cocoa and FLTK would be the least bloated ones. I am planning to create video phone software and I was looking for good GUI toolkit that supports FRP so it looks like it is right time to use Grapefruit :) This would be really great. Writing applications with Grapefruit gives me useful feedback and pressure for improvement. Note that currently the set of supported widgets is very low but this is likely to change during the next weeks and it should often be very easy to port Gtk2Hs widgets to Grapefruit. Awesome! I'll be looking forward start using Grapefruit soon! :) Thanks Jamie Best wishes, Wolfgang Jamie Clark___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
On Mon, 16 Feb 2009, Wolfgang Jeltsch wrote: [redirecting to haskell-cafe] Am Sonntag, 15. Februar 2009 00:25 schrieben Sie: Hi Wolfgang, I was wondering if I can use FLTK as GUI backend for Grapefruit? This should be possible in principal. It just could be that my assumptions about how widgets are created and composed were too tight so that Grapefruit’s general interface doesn’t fit FLTK. In this case, please just tell me and I will try to make the interface more general. Ok, great I ll have to use them then I will see and know what improvement is needed. I believe for this to make it happen, I would have to output FLTK's C++ into C then create bindings for Haskell (via FFI). Is that doable or an quite tall order? Recently, a student of mine has written a program which generates a Haskell Qt binding fully automatically from Qt header files. The generated binding consists of three layers. The first layer is C++ code which reexports Qt’s functionality as a pure C interface. The C interface is ugly for humans and not type safe (because C doesn’t know classes). The second layer consists of a couple of FFI declarations. The third layer is Haskell code which provides a nice interface similar to the original C++ interface. I still have to get the source code of the binding generator from that student but I hope this will happen soon. I want to publish it then on the web. It hope that it is possible to reuse this binding generator for other C++ libraries. That would be very helpful, I ll be looking forward. Best wishes, Wolfgang Jamie___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
On Mon, 16 Feb 2009, Wolfgang Jeltsch wrote: [redirecting to haskell-cafe] Am Sonntag, 15. Februar 2009 00:26 schrieben Sie: One more thing, would Grapefruit work with files created by Glade (UI builder)? No, it won’t, I’m afraid. There is, for example, the principal problem that Glade is GTK+-specific (as far as I know) while Grapefruit shall have a toolkit-independent library interface. However, I don’t think it is such a good idea to support traditional GUI builders. These builders typically let you design a static interface but you have to code event handlers or similar stuff completely by hand and you have practically no support for dynamic user interfaces (user interfaces that change their structure). On the other hand, Grapefruit uses arrow notation for composing user interfaces so that the source code already reflects the visual appearence of the GUI to a certain degree. For example, you just list the widgets of a box and say what their input and output signals are. Make sense. That said, I still think it might be a good idea to use a GUI builder together with Grapefruit. But such a builder should be specifically designed for Grapefruit, in my opinion. I already have some rough ideas in my mind about how such a builder could work. I’d want it to cover also the communication between the UI components (using signals) and maybe even dynamic user interfaces. If you are interested in my ideas, please ask. That would be a great addition to Grapefruit. Time for me to read fully about FRP and arrow notation and go from there! Best wishes, Wolfgang Jamie___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Am Montag, 16. Februar 2009 15:13 schrieben Sie: So I have an application that I am developing. The UI module includes the following: import Graphics.UI.Gtk import Graphics.Rendering.Cairo import Graphics.Rendering.Cairo.SVG import Graphics.UI.Gtk.Gdk.EventM Can you tell from that list if i am likely to be able to rewrite it to use Grapefruit? No, this won’t work at the moment. As I already said, Grapefruit’s widget support is very restricted at the moment. (And if I say “very” I really mean it.) So Grapefruit is worlds apart from what the catch-all Graphics.UI.Gtk import provides. And there is no graphics support at the moment, so there is nothing equivalent to the Cairo interface. Coming up with a sensible purely-functional, toolkit-independent, reactive graphics interface will also need some design work. Until now, I concentrated on getting Grapefruit’s core well. This includes a scalable FRP implementation, a record system (since you don’t want to provide an input signal for every attribute of every single widget in practice) and support for writing/extending Grapefruit UI backends without writing lots of boilerplate code. Providing a wide variety of ready-to-use widgets, graphics primitives, etc. is future work which, hopefully, I can delegate largely to interested third parties. ;-) Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Wolfgang == Wolfgang Jeltsch g9ks1...@acme.softbase.org writes: Hello Wolfgang, congratulation for your Grapefruit release! Wolfgang This would be really great. Writing applications with Wolfgang Grapefruit gives me useful feedback and pressure for Wolfgang improvement. Note that currently the set of supported widgets Wolfgang is very low but this is likely to change during the next weeks Wolfgang and it should often be very easy to port Gtk2Hs widgets to Wolfgang Grapefruit. Hey, this sounds wonderful :-D Do you anticipate that Grapefruit will be capable for writing real-world GUI apps quit soon? Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D pgp45LJUmrNGt.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
2009/2/16 Gour g...@mail.inet.hr Do you anticipate that Grapefruit will be capable for writing real-world GUI apps quit soon? LOL. Funny typo. If the apps quit soon we're in trouble! :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
I would actually quite like to integrate Hieroglyph with Grapefruit, which would give you your Cairo support and give me a sensible way to implement events outside of my really rather broken model. On Mon, Feb 16, 2009 at 10:04 AM, Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: Am Montag, 16. Februar 2009 15:13 schrieben Sie: So I have an application that I am developing. The UI module includes the following: import Graphics.UI.Gtk import Graphics.Rendering.Cairo import Graphics.Rendering.Cairo.SVG import Graphics.UI.Gtk.Gdk.EventM Can you tell from that list if i am likely to be able to rewrite it to use Grapefruit? No, this won't work at the moment. As I already said, Grapefruit's widget support is very restricted at the moment. (And if I say very I really mean it.) So Grapefruit is worlds apart from what the catch-all Graphics.UI.Gtk import provides. And there is no graphics support at the moment, so there is nothing equivalent to the Cairo interface. Coming up with a sensible purely-functional, toolkit-independent, reactive graphics interface will also need some design work. Until now, I concentrated on getting Grapefruit's core well. This includes a scalable FRP implementation, a record system (since you don't want to provide an input signal for every attribute of every single widget in practice) and support for writing/extending Grapefruit UI backends without writing lots of boilerplate code. Providing a wide variety of ready-to-use widgets, graphics primitives, etc. is future work which, hopefully, I can delegate largely to interested third parties. ;-) Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Peter == Peter Verswyvelen bugf...@gmail.com writes: Peter 2009/2/16 Gour g...@mail.inet.hr Do you anticipate that Grapefruit will be capable for writing real-world GUI apps quit soon? Peter LOL. Funny typo. If the apps quit soon we're in trouble! Peter :-) Nay - it just shows the GHC optimiser is performing beyond our wildest dreams :-) -- Colin Adams Preston Lancashire ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Peter == Peter Verswyvelen bugf...@gmail.com writes: Peter LOL. Funny typo. If the apps quit soon we're in trouble! :-) Well, let's do some LOL-ing on my own account... Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D pgpyn3RTL8clR.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
I apologize, I did not mean to be rude at all, I found it a great typo to summarize the previous attempts for doing fully functional GUIs in Haskell. 2009/2/16 Gour g...@mail.inet.hr Peter == Peter Verswyvelen bugf...@gmail.com writes: Peter LOL. Funny typo. If the apps quit soon we're in trouble! :-) Well, let's do some LOL-ing on my own account... Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Am Montag, 16. Februar 2009 16:43 schrieb Peter Verswyvelen: 2009/2/16 Gour g...@mail.inet.hr Do you anticipate that Grapefruit will be capable for writing real-world GUI apps quit soon? LOL. Funny typo. If the apps quit soon we're in trouble! :-) I’m sure that current Grapefruit applications will be quitted soon by their users. :-D Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Am Montag, 16. Februar 2009 16:27 schrieb Gour: Do you anticipate that Grapefruit will be capable for writing real-world GUI apps quit soon? I have no concrete anticipation. It depends very much on the community. If there is notable interest and this interest makes people hacking on Grapefruit then it might not take so long until you can write real-world apps in Grapefruit. I’m really interested in developing Grapefruit further. However, I also have to do a PhD, etc. and so I need others which help. But I will try to help the helpers as much as possible and also hack myself. Various immediate reactions to my release announcement make me hopeful that there might be indeed notable Grapefruit development from other people than me. Best wishes, Wolfgang P.S.: The “hack myself” might not be a typo but it’s maybe a funny blooper. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Am Montag, 16. Februar 2009 17:46 schrieb Wolfgang Jeltsch: Am Montag, 16. Februar 2009 16:27 schrieb Gour: Do you anticipate that Grapefruit will be capable for writing real-world GUI apps quit soon? I have no concrete anticipation. It depends very much on the community. If there is notable interest and this interest makes people hacking on Grapefruit then it might not take so long until you can write real-world apps in Grapefruit. By the way, are there people out there who would like to hack on Grapefruit during the Utrecht Hackathon [1]? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Fwd: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Am Montag, 16. Februar 2009 18:05 schrieb Fraser Wilson: I'd love to hack on Grapefruit. That’s great! I'll do some study (and take a break from my own world-changing functional GUI :-) I tried to check out your repository at http://thewhitelion.org/darcs/barrie/ but darcs get failed with some complaint about cached patches or so. :-( I use darcs 2.2.1. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Yeah, I lack some darcs fu unfortunately. I understood it was just a matter of copying a repository. I'll have a look, and by have a look I mean bother #haskell :-) Cheers, Fraser Sent from my iPhone On 16 feb 2009, at 18:51, Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: Am Montag, 16. Februar 2009 18:05 schrieb Fraser Wilson: I'd love to hack on Grapefruit. That’s great! I'll do some study (and take a break from my own world-changing functional GUI :-) I tried to check out your repository at http://thewhitelion.org/darcs/barrie/ but darcs get failed with some complaint about cached patches or so. :-( I use darcs 2.2.1. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Am Montag, 16. Februar 2009 19:08 schrieben Sie: Yeah, I lack some darcs fu unfortunately. I understood it was just a matter of copying a repository. I'll have a look, and by have a look I mean bother #haskell :-) If you don’t use this lazy fetch feature (or whatever it is called) then you can just copy your repository. Personally, I have very uncomfortable feelings about this lazy patch fetching since I fear it might be all too easy to loose data somewhere. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: first Grapefruit release
Am Montag, 16. Februar 2009 19:27 schrieben Sie: Ah. Copy, don't darcs get. If you copy a repository which was itself fetched from somewhere using this lazy patch fetching feature, you’ll probably experience problems too. If it’s the repository you work in and you never fetched any patches into it, you might be successful. This is how I understand it. We see that this lazy patch fetching thing is dangerous. ;-) If you want to take a look, I'd love to hear your thought. demos/BarrieCalc has some commentary, and the other applications in demos are all very simple. I just executed the demos. At the moment, I have no time to look at the code but I think I will have a look in the future. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
