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 interpret
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
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 wh
Thanks, Bob.
On Mon, Feb 2, 2009 at 11:42 PM, Thomas Davie wrote:
>
> On 3 Feb 2009, at 08:12, Achim Schneider wrote:
>
> "John A. De Goes" wrote:
>>
>>
>>> Perhaps I should have been more precise:
>>>
>>> How do you define "layout" and "interaction semantics" in such a way
>>> that the former
On Tue, Feb 3, 2009 at 5:49 PM, John A. De Goes 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
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
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
On 3 Feb 2009, at 08:12, Achim Schneider wrote:
"John A. De Goes" 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 o
"John A. De Goes" 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
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" 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.
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 wrote:
> That's my thought.
>
> On Mon, Feb 2, 2009 at 7:23 AM, Achim Schneider wrote:
> > Stephen Tetley wrote:
> >
> >>
That's my thought.
On Mon, Feb 2, 2009 at 7:23 AM, Achim Schneider wrote:
> Stephen Tetley 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.
>>
> Y
Stephen Tetley 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 t
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
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
>> 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
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
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 / MSy
Cool! Looking forward to it.
On Mon, Feb 2, 2009 at 12:10 AM, Jeff Heard 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 o
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 wrote:
> Everyone, I'll be releasing Hieroglyph this week. Right now I'm unit
> testing and I'
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 :
> Hi Conal,
> Do you have any links to this interesting work of Jefferson Heard? Blogs or
> something? I failed to Google it, I mainly f
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 ei
Hi Conal,
On Sat, Jan 31, 2009 at 12:10 AM, Conal Elliott 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 go
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, t
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 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 tha
"Claus Reinke" 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 hav
Peter Verswyvelen 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 wo
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 on
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 Z
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.
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 rend
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. "Smoot
Conal Elliott 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
> i
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 fun
Achim Schneider 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 sign
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 wrote:
> I found Cairo rather slow, even on the fastest hardware.
>
> Maybe OpenVG will take off one day:
> http:/
Antony Courtney 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, th
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 :
> 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-lev
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 filli
On Fri, Jan 30, 2009 at 4:25 PM, Bryan O'Sullivan wrote:
> On Fri, Jan 30, 2009 at 1:11 PM, Antony Courtney
> 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
2009/1/30 Bryan O'Sullivan :
> On Fri, Jan 30, 2009 at 1:11 PM, Antony Courtney
> 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 whet
On Fri, Jan 30, 2009 at 1:11 PM, Antony Courtney
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 sh
On Fri, Jan 30, 2009 at 3:50 PM, Achim Schneider wrote:
> Antony Courtney 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 app
Antony Courtney 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
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
2009/1/30 Rick R
> 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
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
On Fri, Jan 30, 2009 at 2:21 AM, Evan Laforge 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 c
> "Conal" == Conal Elliott 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 philoso
On Fri, 30 Jan 2009 15:21:05 +0800
Evan Laforge 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
> 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 thos
2009/1/29 Gour
> > "Conal" == Conal Elliott 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> si
> "Conal" == Conal Elliott 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 (denotation
John Lato 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
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
58 matches
Mail list logo
