[Gtk2hs-devel] Re: Good news about cairo/hscairo and Gtk2Hs

[Duncan C. <dun...@wo...>]

On Thu, 2005-06-30 at 11:15 -0400, Abraham Egnor wrote:
> Congratulations, Paolo!  Hopefully you'll receive this before your
> 'net connection goes dark.  Some quick comments on the various aspects
> of the project:
> 
> hscairo current uses darcs for version control; unless you have
> compelling reason otherwise, I'd very much like to keep this the case.
>  I'm happy for the canonical download location for hscairo to shift to
> wherever you can host your own repository.

That's a good idea. Gtk2Hs currently uses CVS but it is certainly not
ideal. If we were starting the project now we would certainly use darcs.

We could probably temporarily host a hscairo darcs repository in the
Gtk2Hs webspace on haskell.org. A longer term solution might be to ask
for the use of http://haskell.org/hscairo/

> One obvious task, of course, is to update hscairo to match the current
> cairo API in CVS.  I'd been holding off on doing this myself because
> cairo is going though an official API shakeup; however, I think that's
> largely finished at this point.

So the version in darcs on your site is the latest version of your code
I assume. http://ofb.net/~abe/darcs/cairo

> Currently the binding is somewhat minimalist in that it uses
> hand-written FFI imports, with hsc2hs providing the machine-dependent
> bits.  If there's an FFI code generator you'd prefer to use, by all
> means do so.

We were thinking of using c2hs. I don't think it would be too hard to
convert, indeed in most places it will actually involve deleting code.

> My strong preference would be to keep hscairo as a separate library
> from Gtk2Hs, as it has both standalone utility and is likely to be
> used in other libraries as cairo grows in popularity.

Yes this is a good goal. For the short term of Paolo's project we may
have to compirimise and leave this packaging issue for later work. In
fact we do have longer to resolve it since Gtk2Hs + hscairo will not
quite reach fruition for most users until Gtk+ 2.8 is released with it's
cairo integration. I think Gtk+ 2.8 is still some months away.

> An interesting sticking point is the use of attributes (i.e. x =: y in
> hscairo, x := y in Gtk2Hs).  The hscairo attribute system is actually
> provided by a separate library, Data.Attribute; if said library can be
> modified to acommodate both hscairo and Gtk2Hs needs, that would be
> ideal.

Actually, Paolo and I were reviewing the differences in the two
attributes modules yesterday and came to the conclusion that they are
very similar and could be merged and shared quite easily.

There are some internal implementation difference that do not really
affect the user api, eg you use classes for readable and writeable
attributes whereas we represent those slightly differently. Then your
library has the concept of a 'global' attribute by making the object
just the unit type (). This is something that we can add in the same
way. Similiarly, your library is generalsied over the monad. Our current
version uses just the IO monad but it could easily be paramaterised over
the monad in the same way that your library does.

The only remaining difference is in the names of the operators. I'd
rather stick with the names we've got ':=' since it is the same as what
wxWidgets and hs-fltk use.

Also as a longer term packaging goal it'd be great to share the
Data.Attributes implementation between Gtk2Hs and hscairo probably as a
seperate 'cabalised' package.

> Please feel free to contact me with any further questions, comments,
> concerns, etc.

So how about this for a short term and long term plan for packaging:

Short term:
To make Paolo's life easier we have him host the darcs repo for his
hscairo fork (possibly using Gtk2Hs web space) and have it depend on
Gtk2Hs and use the attributes API that is part of the Gtk2Hs glib
package (we would obviously have to generalise it to accomodate the
needs of hscairo).

Longer term:
Update the Data.Attributes module to an interface and implementation
that can be shared by Gtk2Hs and hscairo. Distribute hscairo seperately,
depending only on the Data.Attributes package (as it is now) and have
Gtk2Hs depend on hscairo, and have both projects packaged and
distributed seperately (though we would probably need to coordinate
releases to ensure compatability).

I can send a seperate email describing in more detail the changes we
would need to make to be able to share the Data.Attributes module,
including an initial implementation for review.

I suggest that we conduct these discussions on the Gtk2Hs development
mailing list (which I've cc'd): gtk...@li...
(this is partly just so that Paolo's mentor at Google can keep up with
developments)

Duncan