On Fri, 2005-06-24 at 11:54 -0400, Abraham Egnor wrote:
> A note: I wrote an almost-complete binding to Cairo; it won't compile
> against current CVS, sadly, as I'm waiting for the API shakeup to
Last time I tried it, I had it working with cairo version 0.3 I think.
Do you have any insight into when the cairo API might stabalise? I've
seen that cairo 0.4 and 0.5 had lots of changes but it seemd they
suggested that the API churn is slowing down.
For APIs like this one that are still changing, I'd highly reccomend
using c2hs rather than hsc2hs. It automates much of the tedious work in
writing FFI declerations but the best feature is that c2hs verifies that
the Haskell/C types match up, so if the underlying C function prototype
changes then you'll get a type error rather than a segfault.
> I suspect that it should either be a included with Gtk2HS or
> a build dependency for such, to avoid duplicating effort.
Yes we want to avoid duplicating effort too! :-)
>From our point of view, a tight integration into Gtk2Hs would be easier
(and it's not unreasonable since Gtk is probably the main cairo user at
the moment) however I understand that you might like too keep it as a
seperate standalone library since it can be used on it's own eg for
generating ps/pdf/svg/png etc.
One difficulty at the moment for a good integration that we'd hope to
work with you on, is that both hscairo and Gtk2Hs use a
attributes/properties API with operators like:
set obj [ attr := value ]
(though if I recall correctly you're using (=:)). Anyway, obviously for
a user to use these two libraries together in any sane way we'd really
have to be using the same properties API.
The form of our properties API is motivated by the desire to be
compatible with other GUI libs like wxHaskell, Yampa and hs-fltk. I
wonder if we couldn't modify your Data.Attribute library to provide an
attributes API that both projects can share. Of course having such a
package that we both depend on does make distribution more complex which
is why I say that from a purely selfish point of view it'd be easier for
us to just include hscairo with Gtk2Hs.
BTW, what is the license of hscairo? is it the same as for cairo, ie
On another note, you'll be interested to know that a student has applied
to the Google Summer of Code programme with a project proposal to add
cairo/hscairo integration to Gtk2Hs. So if he is sucessful in his
application we should gain a developer with a great deal of time to
dedicate to these issues.