[Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
John A. De Goes wrote: The size, color, and layout of widgets has no effect on interaction semantics and is best pushed elsewhere, into a designer-friendly realm such as CSS. Yes, layout can be separated from interaction. It's just that I don't consider CSS friendly at all, I'd say it's a 0th order language. Layout combinators in the spirit of TeX or Lout are more flexible while being simpler. In any case, a simple primitive grid :: [[Rect a]] - Rect a that arranges widgets in a rectangular grid should be enough for GUIs. Regards, apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
On Feb 3, 2009, at 2:10 AM, Heinrich Apfelmus wrote: It's just that I don't consider CSS friendly at all, I'd say it's a 0th order language. I never said, CSS, I said like CSS. Layout combinators in the spirit of TeX or Lout are more flexible while being simpler. In any case, a simple primitive grid :: [[Rect a]] - Rect a that arranges widgets in a rectangular grid should be enough for GUIs. Spoken like a true programmer who knows nothing about usability. :-) Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
On Tue, Feb 3, 2009 at 5:49 PM, John A. De Goes j...@n-brain.net wrote: I never said, CSS, I said like CSS. Oh, I missed the like word! What do you mean with that? What aspects of CSS do you prefer to? In WPF a style is basically just a bunch of attribute key/value pairs. Layout combinators in the spirit of TeX or Lout are more flexible while being simpler. In any case, a simple primitive grid :: [[Rect a]] - Rect a that arranges widgets in a rectangular grid should be enough for GUIs. Spoken like a true programmer who knows nothing about usability. :-) Yes, layout must be very versatile and user definable. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
Thanks, Bob. On Mon, Feb 2, 2009 at 11:42 PM, Thomas Davie tom.da...@gmail.com wrote: On 3 Feb 2009, at 08:12, Achim Schneider wrote: John A. De Goes j...@n-brain.net wrote: Perhaps I should have been more precise: How do you define layout and interaction semantics in such a way that the former has a *necessarily* direct, enormous impact on the latter? HTML/CSS is a perfect example of how one can decouple a model of content from the presentation of that content. The developer writes the content model and the controller, while UX guys or designers get to decide how it looks. HTML, or rather XML, would be layout to me. GUI's usually don't serve static content, and allowing a CSS layer to position eg. a filter GUI that supports chaining up any amount of filters by slicing them apart and positioning them on top of each other (maybe because someone didn't notice that you can use more than one filter) wrecks havoc on both usability and the semantics. Wrecks havoc on the semantics in the sense of that if a thing is editable, the semantics should guarantee that it is, indeed, editable. Likewise, if something is marked as visible (and such things are explicit in the model, not defined by an outer layer), the semantics should guarantee that it is visible. I mostly don't get how a topic discussing how to do GUIs in a beautiful, consistent, composable, orthogonal, functional way got onto the topic of oh hay, you could do it with html and css. Sure, those two may be declarative languages, but that doesn't make either of them fill the list of features required above! Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
John A. De Goes wrote: Layout combinators in the spirit of TeX or Lout are more flexible while being simpler. In any case, a simple primitive grid :: [[Rect a]] - Rect a that arranges widgets in a rectangular grid should be enough for GUIs. Spoken like a true programmer who knows nothing about usability. :-) Hehe, well given that CSS doesn't even have such a primitive... :) Regards, apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
On Tue, 2009-02-03 at 13:18 -0700, John A. De Goes wrote: Nor does it need one: http://www.csszengarden.com/ Can I write one if I really, really want to? I don't think excluding programmers from control over layout is much better than excluding non-programmers, really. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
CSS is purely declarative in nature and entirely deterministic. Moreover, it's expressive power is such that you can completely and radically alter the look of a website with modifications to CSS alone (see Zen Garden). The grammar and semantics are relatively simple and can be interpreted and generated by tools, which means that a designer can work with CSS files without knowing anything about CSS. Is it perfect? No. But it's a lot better than trying to encode everything in a single language that only a software developer can safely work with. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 3, 2009, at 10:09 AM, Peter Verswyvelen wrote: On Tue, Feb 3, 2009 at 5:49 PM, John A. De Goes j...@n-brain.net wrote: I never said, CSS, I said like CSS. Oh, I missed the like word! What do you mean with that? What aspects of CSS do you prefer to? In WPF a style is basically just a bunch of attribute key/value pairs. Layout combinators in the spirit of TeX or Lout are more flexible while being simpler. In any case, a simple primitive grid :: [[Rect a]] - Rect a that arranges widgets in a rectangular grid should be enough for GUIs. Spoken like a true programmer who knows nothing about usability. :-) Yes, layout must be very versatile and user definable. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
Nor does it need one: http://www.csszengarden.com/ Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 3, 2009, at 10:45 AM, Heinrich Apfelmus wrote: John A. De Goes wrote: Layout combinators in the spirit of TeX or Lout are more flexible while being simpler. In any case, a simple primitive grid :: [[Rect a]] - Rect a that arranges widgets in a rectangular grid should be enough for GUIs. Spoken like a true programmer who knows nothing about usability. :-) Hehe, well given that CSS doesn't even have such a primitive... :) Regards, apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
Although efficient text rendering (or more generally, massive similar shape rendering) requires a lot of clever caching I guess :) On Mon, Feb 2, 2009 at 3:26 PM, Jeff Heard jefferson.r.he...@gmail.comwrote: That's my thought. On Mon, Feb 2, 2009 at 7:23 AM, Achim Schneider bars...@web.de wrote: Stephen Tetley stephen.tet...@gmail.com wrote: Also, Shiva-VG - http://sourceforge.net/projects/shivavg - the implementation of OpenVG that the Haskell binding works with supports OpenVG 1.0.1, so it doesn't handle text at all. You know, if the Haskell bindings are compositable enough, it shouldn't be a problem to simply load bezier shapes from freetype into other libraries. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
Stephen Tetley stephen.tet...@gmail.com wrote: Also, Shiva-VG - http://sourceforge.net/projects/shivavg - the implementation of OpenVG that the Haskell binding works with supports OpenVG 1.0.1, so it doesn't handle text at all. You know, if the Haskell bindings are compositable enough, it shouldn't be a problem to simply load bezier shapes from freetype into other libraries. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
That's my thought. On Mon, Feb 2, 2009 at 7:23 AM, Achim Schneider bars...@web.de wrote: Stephen Tetley stephen.tet...@gmail.com wrote: Also, Shiva-VG - http://sourceforge.net/projects/shivavg - the implementation of OpenVG that the Haskell binding works with supports OpenVG 1.0.1, so it doesn't handle text at all. You know, if the Haskell bindings are compositable enough, it shouldn't be a problem to simply load bezier shapes from freetype into other libraries. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
Hi Jeff Thanks. OpenVG is an interesting bit of kit, however... VGU - the higher level layer - would be hard pressed to be less like Haskell, you draw shapes and lines while passing a path handle around. Also, Shiva-VG - http://sourceforge.net/projects/shivavg - the implementation of OpenVG that the Haskell binding works with supports OpenVG 1.0.1, so it doesn't handle text at all. Text functions were added to the OpenVG at version 1.1. In the short term, this limits the usefulness of OpenVG, but if the implementations develop it does look like a good prospect. Stephen 2009/2/2 Jeff Heard jefferson.r.he...@gmail.com: I will happily check it on Linux. I'm only vaguely familiar with OpenVG... In theory it's a good API, and would support exactly what I'd need for a backend to Hieroglyph that isn't Cairo based, but we'd still need a good image API and probably to bind to Pango to get text and layout support. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
John A. De Goes j...@n-brain.net wrote: How do you define layout in a way that has a direct an enormous effect on interaction semantics??? http://www.youtube.com/watch?v=faJ8N0giqzw -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
Perhaps I should have been more precise: How do you define layout and interaction semantics in such a way that the former has a *necessarily* direct, enormous impact on the latter? HTML/CSS is a perfect example of how one can decouple a model of content from the presentation of that content. The developer writes the content model and the controller, while UX guys or designers get to decide how it looks. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 2, 2009, at 9:47 PM, Achim Schneider wrote: John A. De Goes j...@n-brain.net wrote: How do you define layout in a way that has a direct an enormous effect on interaction semantics??? http://www.youtube.com/watch?v=faJ8N0giqzw -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
John A. De Goes j...@n-brain.net wrote: Perhaps I should have been more precise: How do you define layout and interaction semantics in such a way that the former has a *necessarily* direct, enormous impact on the latter? HTML/CSS is a perfect example of how one can decouple a model of content from the presentation of that content. The developer writes the content model and the controller, while UX guys or designers get to decide how it looks. HTML, or rather XML, would be layout to me. GUI's usually don't serve static content, and allowing a CSS layer to position eg. a filter GUI that supports chaining up any amount of filters by slicing them apart and positioning them on top of each other (maybe because someone didn't notice that you can use more than one filter) wrecks havoc on both usability and the semantics. Wrecks havoc on the semantics in the sense of that if a thing is editable, the semantics should guarantee that it is, indeed, editable. Likewise, if something is marked as visible (and such things are explicit in the model, not defined by an outer layer), the semantics should guarantee that it is visible. That, and I don't intend to write a browser. There will be, of course, a separation between what is displayed and how things are displayed, because that's the very sense of a widget toolkit. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
On 3 Feb 2009, at 08:12, Achim Schneider wrote: John A. De Goes j...@n-brain.net wrote: Perhaps I should have been more precise: How do you define layout and interaction semantics in such a way that the former has a *necessarily* direct, enormous impact on the latter? HTML/CSS is a perfect example of how one can decouple a model of content from the presentation of that content. The developer writes the content model and the controller, while UX guys or designers get to decide how it looks. HTML, or rather XML, would be layout to me. GUI's usually don't serve static content, and allowing a CSS layer to position eg. a filter GUI that supports chaining up any amount of filters by slicing them apart and positioning them on top of each other (maybe because someone didn't notice that you can use more than one filter) wrecks havoc on both usability and the semantics. Wrecks havoc on the semantics in the sense of that if a thing is editable, the semantics should guarantee that it is, indeed, editable. Likewise, if something is marked as visible (and such things are explicit in the model, not defined by an outer layer), the semantics should guarantee that it is visible. I mostly don't get how a topic discussing how to do GUIs in a beautiful, consistent, composable, orthogonal, functional way got onto the topic of oh hay, you could do it with html and css. Sure, those two may be declarative languages, but that doesn't make either of them fill the list of features required above! Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
On Sat, 2009-01-31 at 22:47 +0100, Peter Verswyvelen wrote: I should have mentioned that my tests have been done only on Windows and OSX. Ah, right. Well there are Win32 and Quartz backends too. I guess I would have to try on a system that supports XRender to compare. Unfortunately, the target audience of our application are mostly windows and OSX users, so although it would be great that Cairo performs fast on unix variants, it would be of little value to us, unless of course XRender also runs on Windows/OSX somehow :) I have heard that in some cases there is a mismatch in the semantics of Cairo and Quartz which requires falling back to software rendering in some cases. It may be you're hitting those cases. You could send your examples to the cairo folks: http://cairographics.org/FAQ/#profiling Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
Hi Conal, On Sat, Jan 31, 2009 at 12:10 AM, Conal Elliott co...@conal.net wrote: Hopefully some enterprising Haskell hacker will wrap Cairo in a nice purely functional API. Jefferson Heard is working on such a thing, called Hieroglyph. [...] 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, ...). Exciting! I was very much trying to achieve this with Haven back in 2002: http://www.haskell.org/haven As the slides on that page state pretty explicitly, I tried to focus on the semantics and to design a purely functional representation of a vector graphics scene that was not tied to any particular implementation. My primary claim for success is that the representation of Picture in Haven type checks and doesn't appeal to IO; IO only creeps in when we attempt to render a Picture. Does the Haven API live up to your goal of semantic purity for a vector graphics library? If not, where specifically does it fall short? I look forward to seeing and reading more about Hieroglyph. The typography and visual presentation of Jefferson's online booklet looks fantastic. A high quality, purely functional vector graphics API for Haskell with portable and robust implementations will be a great thing for the Haskell world. Regards, -Antony ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
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 bugf...@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 co...@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.court...@gmail.com wrote: On Fri, Jan 30, 2009 at 4:25 PM, Bryan O'Sullivan b...@serpentine.com wrote: On Fri, Jan 30, 2009 at 1:11 PM, Antony Courtney antony.court...@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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
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 bugf...@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 co...@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.court...@gmail.com wrote: On Fri, Jan 30, 2009 at 4:25 PM, Bryan O'Sullivan b...@serpentine.com wrote: On Fri, Jan 30, 2009 at 1:11 PM, Antony Courtney antony.court...@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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
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.he...@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 bugf...@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 co...@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.court...@gmail.com wrote: On Fri, Jan 30, 2009 at 4:25 PM, Bryan O'Sullivan b...@serpentine.com wrote: On Fri, Jan 30, 2009 at 1:11 PM, Antony Courtney antony.court...@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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
Cool! Looking forward to it. On Mon, Feb 2, 2009 at 12:10 AM, Jeff Heard jefferson.r.he...@gmail.comwrote: 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 bugf...@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 co...@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.court...@gmail.com wrote: On Fri, Jan 30, 2009 at 4:25 PM, Bryan O'Sullivan b...@serpentine.com wrote: On Fri, Jan 30, 2009 at 1:11 PM, Antony Courtney antony.court...@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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
Hello I've written a Haskell binding to the Shiva-VG OpenVG implementation. Hopefully it should appear on Hackage in the next couple of days - but for the moment it is available here: http://slackwise.org/spt/files/OpenVG-0.1.tar.gz I've tested it on MacOSX leopard and Windows with MinGW / MSys, if anyone could check it on Linux that would be handy. Thanks. Best regards Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
Hi Antony, My primary claim for success is that the representation of Picture in Haven type checks and doesn't appeal to IO; IO only creeps in when we attempt to render a Picture. You did something much more meaningful to me that what you say here. It is easy to define a type that satisfies these conditions but is as semantically intractable as IO. As an absurd demonstration, clone some large chunk of the current set of IO primitive interfaces (return, (=), getChar, forkIO, various FFI-imported things, ...) into a GADT called NotIO. Then write a 'render :: NotIO a - IO a' that interprets NotIO as IO. One could call NotIO a purely functional wrapper. Or we could just use IO itself. In the words of Lewis Carroll: That's another thing we've learned from your Nation, said Mein Herr, map-making. But we've carried it much further than you. What do you consider the largest map that would be really useful? *About six inches to the mile.* Only six inches!exclaimed Mein Herr. We very soon got to six yards to the mile. Then we tried a hundred yards to the mile. And then came the grandest idea of all! We actually made a map of the country, on the scale of a mile to the mile! *Have you used it much? I enquired.* It has never been spread out, yet, said Mein Herr: the farmers objected: they said it would cover the whole country, and shut out the sunlight! So we now use the country itself, as its own map, and I assure you it does nearly as well. While my example and Lewis Carroll's are intentionally absurd, I'm concerned that purely functional wrappers can be just as meaningless but less aparently so. I think what you did in Haven (based on memories of our conversations at the time and looking at your slides just now) is substantively different. You gave precise, complete, and tractably simple *denotation* to your types. Complete enough to define the correctness of the rendering process. Does the Haven API live up to your goal of semantic purity for a vector graphics library? If not, where specifically does it fall short? Yes, if my understanding about denotational precision and completeness is correct. Is it? Regards, - Conal On Sun, Feb 1, 2009 at 2:37 PM, Antony Courtney antony.court...@gmail.comwrote: Hi Conal, On Sat, Jan 31, 2009 at 12:10 AM, Conal Elliott co...@conal.net wrote: Hopefully some enterprising Haskell hacker will wrap Cairo in a nice purely functional API. Jefferson Heard is working on such a thing, called Hieroglyph. [...] 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, ...). Exciting! I was very much trying to achieve this with Haven back in 2002: http://www.haskell.org/haven As the slides on that page state pretty explicitly, I tried to focus on the semantics and to design a purely functional representation of a vector graphics scene that was not tied to any particular implementation. My primary claim for success is that the representation of Picture in Haven type checks and doesn't appeal to IO; IO only creeps in when we attempt to render a Picture. Does the Haven API live up to your goal of semantic purity for a vector graphics library? If not, where specifically does it fall short? I look forward to seeing and reading more about Hieroglyph. The typography and visual presentation of Jefferson's online booklet looks fantastic. A high quality, purely functional vector graphics API for Haskell with portable and robust implementations will be a great thing for the Haskell world. Regards, -Antony ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
My primary claim for success is that the representation of Picture in Haven type checks and doesn't appeal to IO; IO only creeps in when we attempt to render a Picture. You did something much more meaningful to me that what you say here. Thanks. ;-) [...] I think what you did in Haven (based on memories of our conversations at the time and looking at your slides just now) is substantively different. You gave precise, complete, and tractably simple *denotation* to your types. Complete enough to define the correctness of the rendering process. Does the Haven API live up to your goal of semantic purity for a vector graphics library? If not, where specifically does it fall short? Yes, if my understanding about denotational precision and completeness is correct. Is it? Yes and no. Yes in the sense that every type in Haven had a simple definition using Haskell's type system and I used these types to specify signatures of a set of functions for 2D geometry that was relatively complete. No in the sense that I never bothered to implement the various geometric functions directly in Haskell; I depended on the underlying implementation to do so. For simple things like points, lines and affine transforms I don't think this should be too controversial, but it's a bit less clear for clipping and constructive area geometry on complicated Bezier paths. From a library user's point of view there isn't much distinction between what I did and a pure implementation, but I can't really claim it's a rigorous or complete semantics without a pure reference implementation, and there's obviously no way to prove claims such as Shapes form a monoid without giving a direct definition of the composition and clipping operators. -Antony ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
I will happily check it on Linux. I'm only vaguely familiar with OpenVG... In theory it's a good API, and would support exactly what I'd need for a backend to Hieroglyph that isn't Cairo based, but we'd still need a good image API and probably to bind to Pango to get text and layout support. For Image APIs, by the way, I suggest that someone, maybe me, but someone, look at the VIPS toolkit, as it's probably already the most Haskell-like toolkit, as it's lazy and concurrent all the way down past the C layer and supports fully composable operators. The authors haven't formalized it as far as functional programming goes, but it was definitely in the back of their brains when they were coming up with it. The other advantage is that the V stands for Very Large. VIPS can handle images of unlimited size. -- Jeff On Sun, Feb 1, 2009 at 7:32 PM, Stephen Tetley stephen.tet...@gmail.com wrote: Hello I've written a Haskell binding to the Shiva-VG OpenVG implementation. Hopefully it should appear on Hackage in the next couple of days - but for the moment it is available here: http://slackwise.org/spt/files/OpenVG-0.1.tar.gz I've tested it on MacOSX leopard and Windows with MinGW / MSys, if anyone could check it on Linux that would be handy. Thanks. Best regards Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
Conal Elliott co...@conal.net wrote: 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. :) I ACCIDENTALLY WHEN IT MADE NO SENSE!! -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
When I said Cairo felt rather slow, I was comparing it again fully hardware accelerated solutions. With Cairo I am unable to perform full smooth screen redraws of even just a single solid rectangle, and when you are making ZUI (zoomable user interfaces), full screen redraws are not uncommon. Smooth here means at least 30 frames per second, but preferably 60 frames per second. It seems not the number of shapes that are rendered is the bottleneck, but the amount of pixels covered. At least that is what I noticed. I guess this is because it is a 100% software renderer, and it might have to perform per pixel conversion when copying to the video card, but I really don't know. It is funny that even the oldest computers outperformed modern desktops in some way. For example on my good old Commodore Amiga (rip) computer a text editor existed that allowed really smooth scrolling of the text (CygnusEd), something I haven't seen on any modern desktop. It's weird we accept the shaky movements of gui elements on almost all operating systems... although with the iPhone, OSX and maybe Windows 7 this will soon be over (not sure about Linux variants, I haven't followed these). IMO the future is fully hardware accelerated rendering on the GPU, like OpenVG. It will take a while before it is common to see glyphs being rendered on the GPU, but I'm sure this is all doable. 2009/1/31 Rick R rick.richard...@gmail.com Cairo is now the graphics back end for Firefox, yes? I thought moving to Cairo resulted in a considerable rendering speedup for FF. On Fri, Jan 30, 2009 at 6:31 PM, Peter Verswyvelen bugf...@gmail.comwrote: I found Cairo rather slow, even on the fastest hardware. Maybe OpenVG will take off one day: http://www.khronos.org/openvg 2009/1/30 Bryan O'Sullivan b...@serpentine.com: Hi, Antony - It's good to see you active on here. It's not clear to me if the Cairo API in its current form supports vector-level clipping or constructive area geometry, [...] The Cairo clipping API is very PostScripty; you set up a path and then turn it into a clip region instead of filling it. You don't end up with a first-class value, but a manipulation of the implicit global rendering state. For CAG-style operations, http://lib2geom.sourceforge.net/ would be a better bet, but FFIing to a library written in C wouldn't necessarily be a real improvement over just writing a CAG library natively. I think it would be true to say that you can't quite get everything you would want in one easy-to-use place, then. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- We can't solve problems by using the same kind of thinking we used when we created them. - A. Einstein ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
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 co...@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.court...@gmail.com wrote: On Fri, Jan 30, 2009 at 4:25 PM, Bryan O'Sullivan b...@serpentine.com wrote: On Fri, Jan 30, 2009 at 1:11 PM, Antony Courtney antony.court...@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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
When I said Cairo felt rather slow, I was comparing it again fully hardware accelerated solutions. .. IMO the future is fully hardware accelerated rendering on the GPU, like OpenVG. It will take a while before it is common to see glyphs being rendered on the GPU, but I'm sure this is all doable. There seem to be some older references to an OpenGL backend for Cairo http://www.cairographics.org/OpenGL/ http://www.freedesktop.org/wiki/Software/glitz http://www.usenix.org/events/usenix04/tech/freenix/nilsson.html aiming for hardware acceleration. There doesn't seem to be anything newer than 2006, though, which is puzzling, as the OpenGL backend is still advertized - is it still supported? A common standard would be useful, but OpenVG doesn't look like ready soon. On the declarative side, there's also SVG.. Claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
On Sat, 2009-01-31 at 13:18 +0100, Peter Verswyvelen wrote: When I said Cairo felt rather slow, I was comparing it again fully hardware accelerated solutions. With Cairo I am unable to perform full smooth screen redraws of even just a single solid rectangle, and when you are making ZUI (zoomable user interfaces), full screen redraws are not uncommon. Smooth here means at least 30 frames per second, but preferably 60 frames per second. It seems not the number of shapes that are rendered is the bottleneck, but the amount of pixels covered. At least that is what I noticed. I guess this is because it is a 100% software renderer, and it might have to perform per pixel conversion when copying to the video card, but I really don't know. The X11 backend is accelerated if your X server supports it. It uses the XRender extension. If you draw to an image surface then yes that is software rendering. If you're happy to be connected to the X server then you can still do off-screen drawing and again if your X server supports it that can be accelerated too. Some X servers accelerate some XRender operations and not others. I think some of the gradient fills are problematic. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
I should have mentioned that my tests have been done only on Windows and OSX. I guess I would have to try on a system that supports XRender to compare. Unfortunately, the target audience of our application are mostly windows and OSX users, so although it would be great that Cairo performs fast on unix variants, it would be of little value to us, unless of course XRender also runs on Windows/OSX somehow :) On Sat, Jan 31, 2009 at 8:54 PM, Duncan Coutts duncan.cou...@worc.ox.ac.ukwrote: On Sat, 2009-01-31 at 13:18 +0100, Peter Verswyvelen wrote: When I said Cairo felt rather slow, I was comparing it again fully hardware accelerated solutions. With Cairo I am unable to perform full smooth screen redraws of even just a single solid rectangle, and when you are making ZUI (zoomable user interfaces), full screen redraws are not uncommon. Smooth here means at least 30 frames per second, but preferably 60 frames per second. It seems not the number of shapes that are rendered is the bottleneck, but the amount of pixels covered. At least that is what I noticed. I guess this is because it is a 100% software renderer, and it might have to perform per pixel conversion when copying to the video card, but I really don't know. The X11 backend is accelerated if your X server supports it. It uses the XRender extension. If you draw to an image surface then yes that is software rendering. If you're happy to be connected to the X server then you can still do off-screen drawing and again if your X server supports it that can be accelerated too. Some X servers accelerate some XRender operations and not others. I think some of the gradient fills are problematic. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
I should have mentioned that my tests have been done only on Windows and OSX. I guess I would have to try on a system that supports XRender to compare. Unfortunately, the target audience of our application are mostly windows and OSX users, so although it would be great that Cairo performs fast on unix variants, it would be of little value to us, unless of course XRender also runs on Windows/OSX somehow :) from the glitz page I refered to: The semantics of glitz are designed to precisely match the specification of the X Render extension. Glitz does not only implement X Render features like component alpha and image transformations, but also support for additional features like convolution filters and color gradients, which are not currently part of the X Render specification. The performance and capabilities of glitz are much dependent on graphics hardware. Glitz does not in any way handle software fall-backs when graphics hardware is insufficient. However, glitz will report if any requested operation cannot be carried out by graphics hardware, hence making a higher level software layer responsible for appropriate actions. Glitz can be used as a stand-alone layer above OpenGL but is also designed to act as a backend for cairo, providing it with OpenGL accelerated output. That's why it would be good to know whether glitz is still supported (and compatible with current cairo): it, or something like it, would provide direct access to hardware-accelerated cairo functionality on all OpenGL platforms (without the current Haskell-land dependency of cairo on Gtk2hs; though software fallbacks for missing hardware support would seem essential). Claus |There seem to be some older references to an OpenGL backend for Cairo | |http://www.cairographics.org/OpenGL/ |http://www.freedesktop.org/wiki/Software/glitz |http://www.usenix.org/events/usenix04/tech/freenix/nilsson.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
Peter Verswyvelen bugf...@gmail.com wrote: I should have mentioned that my tests have been done only on Windows and OSX. I guess I would have to try on a system that supports XRender to compare. Unfortunately, the target audience of our application are mostly windows and OSX users, so although it would be great that Cairo performs fast on unix variants, it would be of little value to us, unless of course XRender also runs on Windows/OSX somehow :) You might want to try http://www.straightrunning.com/XmingNotes/ xorg-x11 is, after all, freely available, so I don't see any reason why any platform shouldn't support it, as it's The Standard. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
Claus Reinke claus.rei...@talk21.com wrote: though software fallbacks for missing hardware support would seem essential You mean having widget renderers that don't use any of those frills, don't you? Don't underestimate the breath of the target audience that wants to run things on their sandwich maker... or have processing oomph left to do real work. I don't know how fast eg. mesa renders basic GL in software (at least in comparison to my geForce, it's a slug), but I'd expect it to be a viable choice to render 2d to a dumb framebuffer. GL has also the advantage of being network-transparent[1] and very bandwidth-efficient, at least if you make proper use of display lists and don't use too many different textures. Presenting impressive demos in the spirit of [2] can't have any negative effects (despite users wondering why it doesn't work until they discover that their distribution starts X with --nolisten-tcp) [1]Really. See GLX. [2]http://www.md.chalmers.se/Cs/Research/Functional/Fudgets/demoform.html -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
Cool. But the folks in the GTK2HS mailing list told me Glitz never really took of :-( I hope they are wrong :) On Sun, Feb 1, 2009 at 12:58 AM, Claus Reinke claus.rei...@talk21.com wrote: I should have mentioned that my tests have been done only on Windows and OSX. I guess I would have to try on a system that supports XRender to compare. Unfortunately, the target audience of our application are mostly windows and OSX users, so although it would be great that Cairo performs fast on unix variants, it would be of little value to us, unless of course XRender also runs on Windows/OSX somehow :) from the glitz page I refered to: The semantics of glitz are designed to precisely match the specification of the X Render extension. Glitz does not only implement X Render features like component alpha and image transformations, but also support for additional features like convolution filters and color gradients, which are not currently part of the X Render specification. The performance and capabilities of glitz are much dependent on graphics hardware. Glitz does not in any way handle software fall-backs when graphics hardware is insufficient. However, glitz will report if any requested operation cannot be carried out by graphics hardware, hence making a higher level software layer responsible for appropriate actions. Glitz can be used as a stand-alone layer above OpenGL but is also designed to act as a backend for cairo, providing it with OpenGL accelerated output. That's why it would be good to know whether glitz is still supported (and compatible with current cairo): it, or something like it, would provide direct access to hardware-accelerated cairo functionality on all OpenGL platforms (without the current Haskell-land dependency of cairo on Gtk2hs; though software fallbacks for missing hardware support would seem essential). Claus |There seem to be some older references to an OpenGL backend for Cairo | |http://www.cairographics.org/OpenGL/ |http://www.freedesktop.org/wiki/Software/glitz |http://www.usenix.org/events/usenix04/tech/freenix/nilsson.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
On Fri, 30 Jan 2009 15:21:05 +0800 Evan Laforge qdun...@gmail.com wrote: Is there a description somewhere of what the critical flaws have been and are, and what the current problems are to solve before we can finally have a practical declarative and compositional UI library? In *theory*, that should be in the (recent) research papers themselves, or perhaps in a paper cited by them. I don't know if that's the case, though. (Always annoys me when research papers don't include that.) -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
Conal == Conal Elliott co...@conal.net writes: Conal I don't mind if it takes a while, since I'm confident it'll be Conal worth the wait. Besides, compositionality yields exponential Conal rewards. Conal Some more encouragement from my friends: [snip] I'm with you Conal, at least with the philosophy of your friends. The problem is that by body (aka: skills) cannot offer much help now to resist he army ;) Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D pgpcgm4AJP79Q.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
On Fri, Jan 30, 2009 at 2:21 AM, Evan Laforge qdun...@gmail.com wrote: Conal As Meister Eckhart said, Only the hand that erases can write the Conal true thing. Nicely said... I'm sure you're not the only one desiring to write GUI in genuinely functional toolkit, but, being realistic and considering how many people are working on bindings for those legacy libraries, I doubt we'll see something written from the scratch and usable for Real World Haskell soon ;) I'm vaguely aware that there has been a line of functional-style widget libraries, from fudgets down to developments like arrows and FRP and the various libraries built on that. The fact that the libraries have continued to be research projects and beget further research projects implies that they've had some critical flaws that needed further research. Is there a description somewhere of what the critical flaws have been and are, and what the current problems are to solve before we can finally have a practical declarative and compositional UI library? Here is a message I sent to Conal and the yampa-users list about a year ago with my thoughts on this very topic. Hope this helps. Kind Regards, -Antony Date: Fri, 22 Feb 2008 09:35:48 -0500 From: Antony Courtney antony.court...@gmail.com To: Conal Elliott co...@conal.net Subject: Re: Fruit Cc: Yampa-Users yampa-us...@cs.yale.edu Hi Conal (and Paul and Henrik and everyone else!), Apologies for the delay in replying. Paul is quite right about my day job keeping me quite busy, although I've been enjoying watching the discussion. I think there are several reasons that Fruit never really caught on. First and foremost, Fruit never provided anything close to the full suite of GUI components found in modern UI toolkits (buttons, sliders, scrollbars, check-boxes, text fields, combo boxes, split panes, tabs, menus, toolbars, etc. etc.). I never got much further than implementing labels, buttons, text fields and maybe one or two other components. This wasn't quite as limiting as one might think as Fruit subsumed everything that was possible to do in Fran and had a very powerful vector graphics library underneath (Haven) so one could use Fruit to implement quite sophisticated interactive animations and combine them with the library of other GUI components. But one couldn't realistically expect to download and install Fruit and just start using it to write the next great full-fledged GUI app. in Haskell. This is related to the second reason Fruit didn't catch on, which is that Fruit was built directly on an interactive graphics library, not a standard GUI toolkit. I think that this was the right first step for our research goals of giving a rigorous answer to the question of What is a formal model of a GUI?. But from both a pragmatic and research point of view, the next interesting research problem to solve would be: How can we present the Fruit programming interface (which offers a clean, simple, pure semantic model of a GUI), but implement the individual GUI components using a standard GUI toolkit?. This is actually an interesting implementation challenge since Yampa's switching and dynamics collections mean that absolutely anything can happen to the widget hierarchy from one time step to the next. You really, really don't want to destroy and rebuild the entire widget hierarchy of the application at every time step, so figuring out how to do some kind of sample-to-sample differencing of the widget hierarchy would be essential. It's not obvious how to do this, which is probably why FranTk and wxFruit took a bit more of a pragmatic approach and exposed bits of the imperative programming model of the underlying toolkit for widget creation and destruction. Another important point is that even the bits of fruit that were implemented involved a number of different dependent parts, so it was always a bit more work to download and install than I would have liked. I was hell-bent on using a vector graphics library as the foundation. Unfortunately there was no widely-available cross-platform vector graphics library implemented in C. So I chose to use Java2D, which meant that I had to build my own system for Haskell/Java interoperability (GCJNI, later hsjni) and a Haskell vector graphics library (Haven) on top of that. So if one wanted to play with fruit, it was necessary to download and install Java, gcjni, haven, yampa and fruit. And in the early days one also had to grab greencard and the arrows preprocessor! I think we did a reasonable job of packaging these given the severe limits of Haskell packaging and build tools at the time, but it was a ton of work and still never made it easy enough for others to experiment casually. Apart from the practicalities of the implementation, I also think there are legitimate pragmatic concerns about using the FRP model to write a full-fledged application. The benefit of using FRP is that it forces the programmer to be explicit
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
I haven't really thought about GUIs much in the last decade, but if one were to embark on such an endeavor, I think an appropriate starting point would be SDL with OpenGL. There would be no very little API structure to hinder the pure functional approach, and it would be portable to a wide variety of platforms. SDL includes support Linux/Win/OSX and now the iPhone. Also you'd have unofficial support for another few platforms. The 1st step would be to build a vector graphics lib for Haskell on OpenGL, but after that, perhaps much of Fruit could be fitted in. (Just a WAG, never heard of the API before now) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
2009/1/30 Rick R rick.richard...@gmail.com I haven't really thought about GUIs much in the last decade, but if one were to embark on such an endeavor, I think an appropriate starting point would be SDL with OpenGL. There would be no very little API structure to hinder the pure functional approach, and it would be portable to a wide variety of platforms. SDL includes support Linux/Win/OSX and now the iPhone. Also you'd have unofficial support for another few platforms. The 1st step would be to build a vector graphics lib for Haskell on OpenGL, but after that, perhaps much of Fruit could be fitted in. (Just a WAG, never heard of the API before now) Well, I've started something like that: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/graphics-drawingcombinators. There are some issues with that library: the semantics are not *quite*right, and its internals are complicated and not easily modified. I want to try again at some point. However, I think before the 1st step, the SDL bindings ought to be easily installable and usable on Windows -- not first assuming Just The Right Setup. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
Wow Luke, this is a nice little package you made :) If you now add support for Bezier curves then you're my hero, then I can get rid of GTK/Cairo for experiments (which turned out to be really slow when rendering large double buffered surfaces...) I also believe that building something on top of OpenGL is the way to go. Too bad that some techniques are patented, like this [1] cool technique for rendering curves directly on the GPU (as far as I know font rendering is still mostly done by the CPU these days) Today hardware is so fast (and tomorrows hardware will double that easily) so that redrawing the whole screen is not an issue anymore, as long as good caching is done to avoid the CPU - GPU bottleneck. Regarding rebuilding the whole GUI tree, actually in modern frameworks (like Microsoft's Windows Presentation Foundation or that Piccolo open source framework) every property of every widget *can* be animated on the fly. [1] http://research.microsoft.com/en-us/um/people/cloop/loopblinn05.pdf 2009/1/30 Luke Palmer lrpal...@gmail.com: 2009/1/30 Rick R rick.richard...@gmail.com I haven't really thought about GUIs much in the last decade, but if one were to embark on such an endeavor, I think an appropriate starting point would be SDL with OpenGL. There would be no very little API structure to hinder the pure functional approach, and it would be portable to a wide variety of platforms. SDL includes support Linux/Win/OSX and now the iPhone. Also you'd have unofficial support for another few platforms. The 1st step would be to build a vector graphics lib for Haskell on OpenGL, but after that, perhaps much of Fruit could be fitted in. (Just a WAG, never heard of the API before now) Well, I've started something like that: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/graphics-drawingcombinators. There are some issues with that library: the semantics are not quite right, and its internals are complicated and not easily modified. I want to try again at some point. However, I think before the 1st step, the SDL bindings ought to be easily installable and usable on Windows -- not first assuming Just The Right Setup. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
Antony Courtney antony.court...@gmail.com wrote: One issue I think you may encounter, though, is that last time I looked, there was still no high-quality, widely available cross-platform 2-D vector graphics library in C or C++! [...] Xrender. It appears to map exceptionally well onto FP, is available everywhere X is available (that includes Windoze and OS X) and usually is heavily hardware-accelerated. Additionally, we already have a pure Haskell implementation of the client-side protocol included in XHB. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
On Fri, Jan 30, 2009 at 3:50 PM, Achim Schneider bars...@web.de wrote: Antony Courtney antony.court...@gmail.com wrote: One issue I think you may encounter, though, is that last time I looked, there was still no high-quality, widely available cross-platform 2-D vector graphics library in C or C++! [...] Xrender. It appears to map exceptionally well onto FP, is available everywhere X is available (that includes Windoze and OS X) and usually is heavily hardware-accelerated. Additionally, we already have a pure Haskell implementation of the client-side protocol included in XHB. According to Wikipedia: The X Rendering Extension (Render or XRender) is an X Window System extension to implement Porter-Duff image compositing in the X server. Porter-Duff image compositing is cool and useful, but it's at a much lower level than what I meant by 2-D vector graphics library. 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. Pretty clear how to build a 2-D Scenegraph library like Piccolo on top of Java2D or Quartz or GDI+; much less clear to me how to build something like that directly on top of XRender. -Antony ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
On Fri, Jan 30, 2009 at 1:11 PM, Antony Courtney antony.court...@gmail.comwrote: 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
2009/1/30 Bryan O'Sullivan b...@serpentine.com: On Fri, Jan 30, 2009 at 1:11 PM, Antony Courtney antony.court...@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. There is an even higher-level interface to Cairo, in the form of the diagrams package[1] [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/diagrams-0.1 --Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
On Fri, Jan 30, 2009 at 4:25 PM, Bryan O'Sullivan b...@serpentine.com wrote: On Fri, Jan 30, 2009 at 1:11 PM, Antony Courtney antony.court...@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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
Hi, Antony - It's good to see you active on here. It's not clear to me if the Cairo API in its current form supports vector-level clipping or constructive area geometry, [...] The Cairo clipping API is very PostScripty; you set up a path and then turn it into a clip region instead of filling it. You don't end up with a first-class value, but a manipulation of the implicit global rendering state. For CAG-style operations, http://lib2geom.sourceforge.net/ would be a better bet, but FFIing to a library written in C wouldn't necessarily be a real improvement over just writing a CAG library natively. I think it would be true to say that you can't quite get everything you would want in one easy-to-use place, then. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
I found Cairo rather slow, even on the fastest hardware. Maybe OpenVG will take off one day: http://www.khronos.org/openvg 2009/1/30 Bryan O'Sullivan b...@serpentine.com: Hi, Antony - It's good to see you active on here. It's not clear to me if the Cairo API in its current form supports vector-level clipping or constructive area geometry, [...] The Cairo clipping API is very PostScripty; you set up a path and then turn it into a clip region instead of filling it. You don't end up with a first-class value, but a manipulation of the implicit global rendering state. For CAG-style operations, http://lib2geom.sourceforge.net/ would be a better bet, but FFIing to a library written in C wouldn't necessarily be a real improvement over just writing a CAG library natively. I think it would be true to say that you can't quite get everything you would want in one easy-to-use place, then. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
Antony Courtney antony.court...@gmail.com wrote: Pretty clear how to build a 2-D Scenegraph library like Piccolo on top of Java2D or Quartz or GDI+; much less clear to me how to build something like that directly on top of XRender. I intended the scene graph to be implemented piece-wise inside, and in terms of, the widgets and merely render with Xrender, something else, or a combination and/or choice of those. Bounding boxes follow directly from the structure of the layout, there's no need to calculate them... a similar argument holds for arbitrary intersections: Widgets just don't overlap. All that stuff fits better into a project like fieldtrip, which of course would be cool to have as a rendering backend. An irc client doesn't even begin to need the same -- compositional -- graphics abilities as say inkscape, it just needs to be able to render stuff next to and over other stuff. To make things even more explicit, the TK should be able to render with ncurses, as long as you don't do any custom paint jobs that you didn't care to implement for ncurses... A 3d modeller implemented with ncurses, software GL and aalib? I guess I'm drifting off. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
Cairo is now the graphics back end for Firefox, yes? I thought moving to Cairo resulted in a considerable rendering speedup for FF. On Fri, Jan 30, 2009 at 6:31 PM, Peter Verswyvelen bugf...@gmail.comwrote: I found Cairo rather slow, even on the fastest hardware. Maybe OpenVG will take off one day: http://www.khronos.org/openvg 2009/1/30 Bryan O'Sullivan b...@serpentine.com: Hi, Antony - It's good to see you active on here. It's not clear to me if the Cairo API in its current form supports vector-level clipping or constructive area geometry, [...] The Cairo clipping API is very PostScripty; you set up a path and then turn it into a clip region instead of filling it. You don't end up with a first-class value, but a manipulation of the implicit global rendering state. For CAG-style operations, http://lib2geom.sourceforge.net/ would be a better bet, but FFIing to a library written in C wouldn't necessarily be a real improvement over just writing a CAG library natively. I think it would be true to say that you can't quite get everything you would want in one easy-to-use place, then. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- We can't solve problems by using the same kind of thinking we used when we created them. - A. Einstein ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
Achim Schneider bars...@web.de wrote: -- compositional -- That's certainly the wrong word, but I think you know what I mean. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
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.court...@gmail.comwrote: On Fri, Jan 30, 2009 at 4:25 PM, Bryan O'Sullivan b...@serpentine.com wrote: On Fri, Jan 30, 2009 at 1:11 PM, Antony Courtney antony.court...@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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
Conal == Conal Elliott co...@conal.net writes: Hi Conal, Conal Hi Achim, I came to the same conclusion: I want to sweep aside Conal these OO, imperative toolkits, and replace them with something Conal genuinely functional, which for me means having a precise Conal simple compositional (denotational) semantics. Something Conal meaningful, formally tractable, and powefully compositional from Conal the ground up. As long as we build on complex legacy libraries Conal (Gtk, wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling Conal against (or worse yet, drawn into) their ad hoc mental models and Conal system designs. Conal As Meister Eckhart said, Only the hand that erases can write the Conal true thing. Nicely said... I'm sure you're not the only one desiring to write GUI in genuinely functional toolkit, but, being realistic and considering how many people are working on bindings for those legacy libraries, I doubt we'll see something written from the scratch and usable for Real World Haskell soon ;) Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D pgpnGI8qzQ6UZ.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
2009/1/29 Gour g...@mail.inet.hr Conal == Conal Elliott co...@conal.net writes: Hi Conal, Conal Hi Achim, I came to the same conclusion: I want to sweep aside Conal these OO, imperative toolkits, and replace them with something Conal genuinely functional, which for me means having a precise Conal simple compositional (denotational) semantics. Something Conal meaningful, formally tractable, and powefully compositional from Conal the ground up. As long as we build on complex legacy libraries Conal (Gtk, wxWidgets, Qt, OpenGL/GLUT, ...), we'll be struggling Conal against (or worse yet, drawn into) their ad hoc mental models and Conal system designs. Conal As Meister Eckhart said, Only the hand that erases can write the Conal true thing. Nicely said... I'm sure you're not the only one desiring to write GUI in genuinely functional toolkit, but, being realistic and considering how many people are working on bindings for those legacy libraries, I doubt we'll see something written from the scratch and usable for Real World Haskell soon ;) Sincerely, Gour Hi Gour, I don't mind if it takes a while, since I'm confident it'll be worth the wait. Besides, compositionality yields exponential rewards. Some more encouragement from my friends: No army can withstand the strength of an idea whose time has come. - Victor Hugo The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. - George Bernard Shaw Regards, - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
Conal As Meister Eckhart said, Only the hand that erases can write the Conal true thing. Nicely said... I'm sure you're not the only one desiring to write GUI in genuinely functional toolkit, but, being realistic and considering how many people are working on bindings for those legacy libraries, I doubt we'll see something written from the scratch and usable for Real World Haskell soon ;) I'm vaguely aware that there has been a line of functional-style widget libraries, from fudgets down to developments like arrows and FRP and the various libraries built on that. The fact that the libraries have continued to be research projects and beget further research projects implies that they've had some critical flaws that needed further research. Is there a description somewhere of what the critical flaws have been and are, and what the current problems are to solve before we can finally have a practical declarative and compositional UI library? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
Achim Schneider wrote: So what's left of those TK's if we don't use their abstractions and replace them with Haskell? Drawing and layouting, that's what's left[3]. Both, IMNSHO, do not justify carrying around bloaty external dependencies, they're too trivial. They certainly don't justify using unsafePerformIO to hide foreign side effects and the headaches associated with it. So, if you don't mind, I'm going to stop trying to fit cubes into round holes and gonna use reactive and fieldtrip[4] to do things. Does this mean you're volunteering to create a fieldtrip-based toolkit with widgets and layout? John Lato ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why binding to existing widget toolkits doesn't make any sense
John Lato jwl...@gmail.com wrote: Achim Schneider wrote: So what's left of those TK's if we don't use their abstractions and replace them with Haskell? Drawing and layouting, that's what's left[3]. Both, IMNSHO, do not justify carrying around bloaty external dependencies, they're too trivial. They certainly don't justify using unsafePerformIO to hide foreign side effects and the headaches associated with it. So, if you don't mind, I'm going to stop trying to fit cubes into round holes and gonna use reactive and fieldtrip[4] to do things. Does this mean you're volunteering to create a fieldtrip-based toolkit with widgets and layout? Most likely, no. fieldtrip uses glut, which only supports one os-level window and is therefore borked for a considerable amount of stuff one wants a TK be able to do. It (currently) also doesn't support orthographic projection, which you need to properly position 2d. In the end, it's a small and great library for stuff you don't need for a TK, and is thus quite unsuited as a platform for one. Fieldtrip widgets are another thing, of course. I'm not volunteering for anything. I'm just hacking away on stuff and following some inspiration I had while I implemented a simplistic widget UI under J2ME, limited to what the game needed. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
