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

[Jeff Heard]

Thanks, Peter, for the paper link...  I'll look at this, as it's
exactly what it sounds like I want for the future of Hieroglyph...

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
>
>