[Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense

[Peter Verswyvelen]

Cool! Looking forward to it.
On Mon, Feb 2, 2009 at 12:10 AM, Jeff Heard <jefferson.r.heard at gmail.com>wrote:

> Everyone, I'll be releasing Hieroglyph this week.  Right now I'm unit
> testing and I've been out of town this past weekend without much
> opportunity to work on it.  It's not yet a complete functional
> re-working of Cairo -- for instance, right now patterns aren't
> supported, and Pango layouts aren't either -- but it should become so.
>  I'll also be forking Hieroglyph to develop a complete,
> pure-functional 2D graphics toolkit.
>
> -- Jeff
>
> 2009/1/31 Peter Verswyvelen <bugfact at gmail.com>:
> > Hi Conal,
> > Do you have any links to this interesting work of Jefferson Heard? Blogs
> or
> > something? I failed to Google it, I mainly found his OpenGL TrueType
> > bindings on Hackage and his
> > beautiful http://bluheron.europa.renci.org/docs/BeautifulCode.pdf
> > Regarding semantics, modern GPUs are able to render 2D graphics (e.g.
> filled
> > or stroked curves) as real functions / relations; you don't need fine
> > tessellation anymore since these computational monsters have become so
> fast
> > that per pixel inside / outside testing are feasible now. It's basically
> a
> > simple form of real-time ray-tracing :)  A quick search revealed another
> > paper using these
> > techniques http://alice.loria.fr/publications/papers/2005/VTM/vtm.pdf
> > Cheers,
> > Peter
> > 2009/1/31 Conal Elliott <conal at conal.net>
> >>
> >> Hi Antony,
> >>
> >>>
> >>> Hopefully some enterprising Haskell hacker will wrap Cairo in a nice
> >>> purely functional API.
> >>
> >> Jefferson Heard is working on such a thing, called Hieroglyph.  Lately
> >> I've been helping him simplify the design and shift it toward a clear,
> >> composable semantic basis, i.e. "genuinely functional" (as in the Fruit
> >> paper), meaning that it can be understood & reasoned about in precise
> terms
> >> via model that is much simpler than IO.
> >>
> >> In the process, I realized more clearly that the *very goal* of making a
> >> purely functional wrapper around an imperative library leads to muddled
> >> thinking.  It's easy to hide the IO without really eliminating it from
> the
> >> semantics, especially if the goal is defined in terms of an IO-based
> >> library.  Much harder, and I think much more rewarding, is to design
> >> semantically, from the ground up, and then figure out how to implement
> the
> >> elegant semantics with the odds & ends at hand (like Cairo, OpenGL, GPU
> >> architectures, ...).
> >>
> >> Regards,
> >>
> >>     - Conal
> >>
> >> On Fri, Jan 30, 2009 at 1:56 PM, Antony Courtney
> >> <antony.courtney at gmail.com> wrote:
> >>>
> >>> On Fri, Jan 30, 2009 at 4:25 PM, Bryan O'Sullivan <bos at serpentine.com>
> >>> wrote:
> >>> > On Fri, Jan 30, 2009 at 1:11 PM, Antony Courtney
> >>> > <antony.courtney at gmail.com>
> >>> > wrote:
> >>> >>
> >>> >> A 2-D vector graphics library such as Java2D ( or Quartz on OS/X or
> >>> >> GDI+ on Windows ) supports things like computing tight bounding
> >>> >> rectangles for arbitrary shapes, hit testing for determining whether
> a
> >>> >> point is inside or outside a shape and constructive area geometry
> for
> >>> >> shape compositing and clipping without dropping down to a raster
> >>> >> representation.
> >>> >
> >>> > These are the kinds of capabilities provided by Cairo, which is very
> >>> > pleasant to use (PDF-style imaging model) and quite portable. There
> are
> >>> > already Cairo bindings provided by gtk2hs, too.
> >>> >
> >>>
> >>> Hi Bryan,
> >>>
> >>> Nice to hear from you!  Been a while...
> >>>
> >>> Just had a quick look and it does indeed appear that Cairo now
> >>> supports some of the features I mention above (bounds calculations and
> >>> hit testing).  Cairo has clearly come a long way from when I was last
> >>> working on Fruit and Haven in 2003/2004;  back then it looked like it
> >>> only provided a way to render or rasterize vector graphics on to
> >>> bitmap surfaces and not much else.
> >>>
> >>> It's not clear to me if the Cairo API in its current form supports
> >>> vector-level clipping or constructive area geometry, and it looks like
> >>> the API is still pretty render-centric (e.g. is it possible to obtain
> >>> the vector representation of rendering text in a particular font?).
> >>> That might make it challenging to use Cairo for something like the
> >>> Haven API, but maybe one can live without that level of generality.
> >>>
> >>> In any case: delighted to see progress on this front!  Hopefully some
> >>> enterprising Haskell hacker will wrap Cairo in a nice purely
> >>> functional API.
> >>>
> >>>    -Antony
> >>> _______________________________________________
> >>> Haskell-Cafe mailing list
> >>> Haskell-Cafe at haskell.org
> >>> http://www.haskell.org/mailman/listinfo/haskell-cafe
> >>
> >>
> >> _______________________________________________
> >> Haskell-Cafe mailing list
> >> Haskell-Cafe at haskell.org
> >> http://www.haskell.org/mailman/listinfo/haskell-cafe
> >>
> >
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090202/ca2ca22d/attachment.htm