[Haskell-cafe] ANNOUNCE: first Grapefruit release
Wolfgang Jeltsch
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.
Grapefruit consists of five packages with several interesting features:
grapefruit-frp: Functional Reactive Programming core
* The FRP implementation uses a hybrid push/pull-based approach.
* Signals can be memoized by binding them to variables – like ordinary
data structures.
* Merging of event streams combines simultaneous events properly.
* Signals cannot behave differently by starting them at different times.
The type system is used to enforce proper aging of signals.
grapefruit-records: A record system for Functional Reactive Programming
* Input records can specify fields as being required or optional.
* Uninteresting output fields can be ignored. The set of interesting
fields is specified by pattern matching.
grapefruit-ui: Declarative user interface programming
* The interface for UI programming is platform-independent and can be
implemented on top of different UI toolkits.
* A concrete implementation can be selected at compile time or runtime.
grapefruit-ui-gtk: GTK+-based implementation of the general UI interface
* Gtk2Hs is used internally.
grapefruit-examples: examples demonstrating features of Grapefruit
* Circular communication and switching are demonstrated.
Support for the following is planned for the future:
* signals with incremental updates
* user interfaces with changing structure
* more kinds of UI components
* graphical animations
Further information about Grapefruit is available on its wiki page at
<http://haskell.org/haskellwiki/Grapefruit>.
If you have questions, applause or criticism, please get in touch with me.
Wolfgang Jeltsch
Principal Grapefruit developer
_______________________________________________
Haskell-Cafe mailing list
Haskel...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Roman Cheplyaka
> 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?
--
Roman I. Cheplyaka :: http://ro-che.info/
"Don't let school get in the way of your education." - Mark Twain
Wolfgang Jeltsch
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
Wolfgang Jeltsch
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
Wolfgang Jeltsch
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
Wolfgang Jeltsch
> Hi Wolfgang,
>
> Thank you for the excellent introduction
Oh, I thought that you didn’t send you original question to the list and
therefore answered you only privately. So the others don’t know yet the
introduction you refer to (but see below).
> (this would be good material to put on your Wiki).
Done. :-)
<http://haskell.org/haskellwiki/Grapefruit/Comparison_to_other_FRP_libraries>
Conal, are you listening? If yes, could you please look over this page to make
sure that I described your work correctly?
Best wishes,
Wolfgang
Wolfgang Jeltsch
> * Wolfgang Jeltsch <g9ks...@acme.softbase.org> [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
Colin Paul Adams
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
Jamie
> [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
Jamie
> [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
Jamie
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
Wolfgang Jeltsch
> 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
Gour
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
----------------------------------------------------------------
Peter Verswyvelen
> 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! :-)
Jeff Heard
which would give you your Cairo support and give me a sensible way to
implement events outside of my really rather broken model.
Colin Paul Adams
Peter> 2009/2/16 Gour <go...@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
Gour
Peter> LOL. Funny typo. If the apps quit soon we're in trouble! :-)
Well, let's do some LOL-ing on my own account...
Peter Verswyvelen
summarize the previous attempts for doing fully functional GUIs in Haskell.
2009/2/16 Gour <go...@mail.inet.hr>
Wolfgang Jeltsch
I’m sure that current Grapefruit applications will be quitted soon by their
users. :-D
Best wishes,
Wolfgang
Wolfgang Jeltsch
> 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.
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
Fraser Wilson
Utrecht is)
Oh, yeah, that's coming up, isn't it? Utrecht finally gets the glory she
deserves (for those who aren't aware, Utrecht has the most beautiful canals
in the Netherlands, which is saying something, and is largely undiscovered
by English bachelor parties, which is why it's such a great place to live).
I think your footnote with what I assume is a link got lost, so here it is:
http://haskell.org/haskellwiki/Hac5
I'd love to hack on Grapefruit. I'll do some study (and take a break from
my own world-changing functional GUI :-)
cheers,
Fraser.
Wolfgang Jeltsch
> 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.
This sounds really interesting. Do you already have some concrete ideas?
The important thing for Grapefruit integration would be to provide signals of
pictures (i.e., time-varying pictures) instead of just static pictures. In
the classic Grapefruit version, we have a graphics package which defines a
special graphic signal type. For the current version, I’d prefer to use
Grapefruit’s standard signal types, applied to an ordinary picture type (type
of static pictures). This would mean a more composable solution (Grapefruit
does time-dependence and interaction and Hieroglyph does graphics).
However, there are situations where it cannot be ignored in Hieroglyph that
pictures can be modified. I think of compound pictures and of lists. These
should be updated incrementally but this wouldn’t work with ordinary lists
etc. Grapefruit is expected to have support for incremental list signals
soon.
By the way, I like your multi-backend approach (Cairo and OpenGL). If
Hieroglyph should act as the standard graphics library to use with
Grapefruit, I would very much like if Hieroglyph’s interface would be
designed as backend-independent as possible. For example, there is also 2D
graphics support in Qt. In my opinion, this would be worth supporting for use
in Qt-based applications. What are your plans concerning Hieroglyph backends?
Wolfgang Jeltsch
> 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.
Fraser Wilson
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
Wolfgang Jeltsch
> 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.
Wolfgang Jeltsch
> 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.
Wolfgang Jeltsch
> * Wolfgang Jeltsch <g9ks...@acme.softbase.org> [2009-02-16 14:51:18+0100]
>
> > 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.
>
Thanks a lot.
> Currently I'm still learning about all these things (FRP, arrows, Grapefruit
> particularly), but if there are things which does not require deep
> understanding of these concepts (or even help to gain one), please tell me.
I think, you need to understand what discrete and segmented signals are. Which
is not very difficult, in my opinion. You only have to know what they mean
not how they are implemented. So you don’t need a deep understanding of all
kinds of FRP things in order to hack on Grapfruit graphics support.
Did you have a look at my e-mail conversation with Jeff Heard (in the same
haskell-cafe thread)? He thinks about adapting the Hieroglyph 2D graphics
library to Grapefruit. There is also the graphics implementation of classic
Grapefruit which is for 3D graphics and OpenGL-based. These may be things,
you want to have a look at.
> Also, I'm yet not sure about Utrecht, but if Grapefruit hacking is
> planned, it's worth coming for me :)
This sounds very good. It’s not yet sure whether I will go to Utrecht for
supervising Grapefruit hacking but it’s very likely that I will.
Wolfgang Jeltsch
> 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?
Henk-Jan van Tuyl
<g9ks...@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/
--
Wolfgang Jeltsch
> 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
Jamie
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
Bulat Ziganshin
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,
Bulat mailto:Bulat.Z...@gmail.com
Jeff Heard
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
<g9ks...@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.
>
Wolfgang Jeltsch
> 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.
Wolfgang Jeltsch
> On Mon, 16 Feb 2009, Wolfgang Jeltsch wrote:
> > [redirecting to haskell-cafe]
> >
> >> 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. :-)
Wolfgang Jeltsch
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