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

[Jeff Heard]

Oh, and by functional, I mean that it isn't a complete re-wrapping of
the library, not that you have IO creeping in all over the place.
Pardon my unclearness.

On Sun, Feb 1, 2009 at 6:10 PM, 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
>>
>>
>