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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 /
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
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
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
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
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.
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
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.
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
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
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
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
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
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
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*,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
58 matches
Mail list logo
