I've been looking at digital cameras, hoping that they will soon become a viable alternative to 35mm photography. I think these people are some of the worst offenders on stretching specs.
Most egregiously, they count the RGB sensors as three separate pixels. By this logic, the laptop I'm typing on has 3072 x 768 pixels; pretty impressive, hm? On the very best of the digital cameras (the Nikon 950), the effective number of pixels (measured using resolution targets) is about half the claimed spec, and even then the image suffers from moire, chromatic aberration, and other artifacts.
What really opened my eyes was looking at Sound Vision's camera, which is only 800 x 600 pixels, but blows away the "megapixel" cameras in total image quality. Unfortunately, because this camera has to take three separate shots through three separate filters (R, G, and B), it's only useful for a limited range of work, so it's foundering.
As if this weren't bad enough, Kodak came out with a digital camera with about a million "pixels", but marketed it as about 1.5M, because they estimated that it delivered quality slightly superior to the 1.3Mpix cameras they were competing with. Can you imagine printers competing on this basis? At least dpi claims have tended to be fairly solid (although I'm more than a bit suspicious over Epson's 1440).
Apparently, all 17 tracks of the soundtrack were leaked last night in.mp3 format. The original server got shut down fairly quickly, alas, so you'll have to hunt them down.
The release of these tracks probably makes the RIAA very unhappy, but I'm not at all convinced of it. It certainly makes me want to go out and buy the soundtrack when it becomes available.
The Gnome/KDE "war" gives us the opportunity to think about competing systems in a totally new way. A lot of people think about it in essentially the same terms as Win vs Mac, but I think this is a narrow view.
There are basically two ways of getting a unified system. You can start with a design for how things Should Be Done, and reject anything that doesn't meet the design. It's a good approach - the Mac has done this with great success. We laugh at newbies who try to put a Mac disk in a PC and expect to run the software. Should we?
The other way to do it is to work to make the pieces integrate well. And this, my friends, is more the Linux Way, if you ask me. We don't talk about NFS vs. Samba vs. Netatalk. You've got a heterogenous network? Run 'em all!
Now, to get KDE and Gnome to seamlessly integrate is quite a challenge, both technically and politically. But I have some hope that the two teams are willing and able to work on it, in a way that Microsoft and Apple never could.
Here's a specific example of what I have in mind. Both Gnome and KDE have some mechanism for "themes", ie the ability to configure the graphical look. What if there were a theme setting application that set the themes of both desktop environments, and so that they're consistent? Ultimately, a person might not need to know or care whether an app is KDE or Gnome - it will be a matter of developer preference.
Of course, this vision takes quite a bit of work. A bi-theme application is quite a bit harder than one for a single desktop. Work will no doubt be required to bring the theme systems in harmony. But I think all of this can and will happen.
I spoke to the reporter for about an hour on this story, and am not too surprised at how it turned out. I think he's missing some major points.
The basic premise, I think, is faulty - that because the GPL hasn't been tested in court, that the status of GPL software is somehow shaky. I think the reverse is actually true, that the free software community is so healthy and is so good at dispute resolution that it has been unnecessary to call in the lawyers.
Think of how many heated technical disputes there have been - should KGI be in the kernel? The Egcs split from Gcc. Gnome vs. KDE. Even the ncurses debacle. All of these have been handled without legal action, and some have been resolved quite nicely (way to go, Gnu compiler folks!).
Now I think it is inevitable that lawyers will come into the fray, especially as there is more and more money in free software. Sooner or later, somebody who's market share is being decimated by free software is going to try to throw a legal monkeywrench into the development process. Other legal threats are also possible.
But the main hypothetical of this article, that a company would flagrantly violate the GPL, seems to me to be outlandish. After all, a snapshot of the code is far from the most valuable part of a vital free software project. It's the knowledge, the community, and the stewardship of keeping the project that's going. Violating the GPL is the surest way of alienating that community and thereby abandoning the benefits from it.
The reporter asked me what I would do if a big company flagrantly violated the GPL of a project I was involved in. My response was that, after making sure that they were in fact in the wrong, and that they had been contacted and turned down the chance to set things right, I wouldn't call a lawyer, I'd post to Slashdot! And I think that would be far more effective. No company wants that kind of bad publicity.
In summary, I think there's something wonderful about the culture of free software that's allowed it to resist the influx of lawyers. I have hope that it can continue to do so.
P.S. I was quoted as "Raph Levien... who develops GIMP". I'm proud to be a part of the large and diverse Gimp development team, but I do want to point out I'm only responsible for a small fraction of the code that's in there.
A couple of comments here. I'm a Gnome developer, and in the Gnome community, there is a serious focus on making Linux truly usable. We talk of the "mom test," i.e. your mom being able to get useful work done with the software.
Real software usability goes deeper than just interactions with GUI dialogs and so on. For experts, Linux is much more usable than the consumer OS's because it is much more stable, more transparent (less things are hidden under the candy shell of the GUI), and has a broader collection of powerful tools. The challenge is going to be preserving this kind of usability while also making Linux more accessible to non-expert users.
One argument that's often made is that Linux suits the needs of expert users because it was designed by expert users. Since we are people who don't mind learning how things really work, and prefer the tools to be powerful once we do learn them, that's reflected in what we build. The argument usually goes on to say that since we don't want pretty but shallow, easy to learn but limited tools, we will never end up building these things for Linux novices.
This argument misses one important point, in my opinion. Even if you accept that the intellectual challenge of building usable software isn't by itself enough to keep the effort going, this argument pretty much assumes that the world is split up into hacker types and lots of isolated people who don't understand their computers. But this is not the full story. Many, many Linux people are sysadmins for a large number of not-so-computer-savvy users. Let me tell you something, Linux people in Windows sysadmin jobs hate having to do several fresh reinstalls of Windows per day per few hundred machines just because the registry gets wedged and there's no way to figure out how to fix it. Many of them would like nothing better than to have Linux become a viable desktop system so they'd be able to at least work with systems they don't hate.
It may well be that these hardy souls turn out to be the vast army that works to make free software usable. Once Linux starts going into the desktop in sysadminned environments, the channels are in place to collect user feedback, and also to do something about it. If such-and-such feature is confusing to users, then the admins will hear about it. It's probably easier in many cases to just fix it than keep dealing with the problem reports, and certainly a hell of a lot more fun.
Don't underestimate the dramatic strides already made in usability by the Linux community. When I first started working with Linux about six years ago, the usual way to install new software was to check the README, edit the Makefile, more often than not fix a few #includes or function prototypes, then run a series of make commands. These days we have RPM packages and so on, but we also have./configure; make. To me, the autoconf system is a classic example of "deep usability" as opposed to the surface kind.
In summary, I think we're just going to keep on going until we get there.
Both of you have done great things for the community, and it's laudable to have differing points of view. But the bickering and personal attacks don't seem to be very helpful.
To quote Tim May about some flame-fest on cypherpunks, you two should just have sex and get it over with.
A while ago, intrigued by the reports of faster typing and so on, I remapped my keyboards to Dvorak to try it out. I think I learned it pretty well, but went back to Qwerty after a few months. I'm glad I switched back.
I have little doubt that many people experience real improvements in typing speed and so on with Dvorak. I also have little doubt that winners of typing contests get an edge from the Dvorak layout. But it only takes a slight edge to win - how much real performance advantage do Speedos really make for swimmers? All Olympic swimmers wear them, but for recreational swimming, the difference is lost in the noise.
I think that the win that people get from learning Dvorak is that they are forced to spend time learning to type correctly. I (and many other hackers I know) have a very sloppy keying style, including moving the hands arounnd and using whichever finger is closest at the time. When I learned Dvorak, I tried to learn it right, and it wasn't possible to go back to being sloppy just out of habit, because then you hit the wrong keys (or, in Dvorak, yd.,prbi t.fo). Training for speed typing would probably be just as effective, but who's motivated to do that?
The irony is that if Dvorak had taken over in the early days, most present-day hackers would get a similar benefit from learning Qwerty:)
The main reason I went back is that I'm often having to deal with other keyboards that haven't been remapped. The cognitive dissonance of having to go back and forth between the two layouts just wasn't worth it, and almost certainly decreased my total performance, even though the burst performance may have been higher when I got into the Dvorak "flow."
The reasoning in the editorial is pretty bogus, though. Just because the value of Dvorak doesn't exceed the cost of retraining does not imply that there's no economic lock-in effect - quite the contrary. It's only if the benefit were exactly zero that this would be the case. The authors have a point that the benefit of Dvorak is not as great as sometimes assumed, but that's not at all the same as claiming it's zero.
Raph, who's glad not to be locked in to either Speedos or swim trunks;)
I'm currently looking into the alphabet soup of standards coming out of the W3C, trying to decide which ones are useful and how they might be applied to free software and Gnome in particular.
There's a lot of interesting things out there. In particular, I think XML and DOM could be the basis for a very good component framework in which powerful components would be easy to write, and would integrate nicely without a lot of hassle. I'm looking at RDF as a piece of this.
But, as far as I can tell, the problem that RDF solves is a bit different than the one mentioned in this article. RDF is a way of representing documents as graph structures, allowing individual files to contain both local and external pieces without everything getting tangled up.
The problem of representing metadata unambiguously is a tricky one, but is not yet solved. The RDF spec presents an interesting outline about how this might be done, but it doesn't quite tell me what I need to do to get my own Web pages to be correctly meta'ed. If I were a library, then the Dublin Core would start to give me the specific markup I needed, but that's just for libraries. What do I use do as metadata for my free software efforts?
It seems like the combination of XML plus XML-NameSpaces plus Dublin Core plus all the other recommendations, specifications, and standards analogous to the Dublin Core but for domains other than libraries might cohere into a workable metadata system for the Web, but on the other hand, the complexity and fuzziness of specification could very easily prevent the beast from flying.
When you're dealing with software, precise specification is key. Some metadata standards have succeeded pretty well in this regard - take MIME content types, for example. If you have a JPEG image, you know that the content type should be "image/jpeg". But the XML crew hasn't even managed a consistent namespace name for HTML 4.0 (I've seen "urn:w3-org-ns:HTML", "http://www.w3.org/TR/REC-html40" and others).
Well, you can start by searching the US Patent and Trademark Office search engine. It's not perfect, but it's fast and well help you cull out the really stupid mistakes.
I have a friend who just lost his trademark because he didn't do a USPTO search, and is regretting it. This time around, we searched pretty damn thoroughly.
I might also suggest that the average is computed with some dummy neutral score added in. That way, if a single person gives a +10 score, it won't go to the top of the list. If lots of people give scores, then you get a true average.
Mathematically, the system I'm proposing is somewhere between the current +1/-1 system and the idea of a simple average.
I really look forward to seeing if Rob can solve the moderation problem. Lots of attempts have failed before, but on the other hand Slashdot has a lot of things going for it that previous systems lacked.
Anyone else noticed the similarity between the current contents of www.linux.com and www.transmeta.com? I think this is evidence of a shadowy Linux conspiracy. My guess is that their goal is nothing short of world domination. Beware!
Just to interject a bit of fact here, libart is definitely not proprietary, nor does it belong in any way to RedHat (though I do realize that the R and H in my name might be confusing:).
In point of fact, I've been in e-mail communication with Roberto Alsina, a KDE developer, about the possbility of using libart to make an antialiased version of Qt's QPaint widget. Since the current libart is entirely LGPL, there are no licensing problems. I personally would love to see this happen. The more wins for libart, the better chance I have making some money licensing libart into the commercial world.
This is work in progress - the antialiased text integration has not been done yet, even though I do have code for smooth antialiased text rendering from type1 outlines. See this screenshot for a "technology demo."
We're looking into that. Of course, this work will be useful even on non-Xfree systems. It can also do alpha-compositing of text and graphics together, which Xfree probably can't do.
I personally am not that happy with the idea of taxpayer funding. No matter what the source of funding, there's the danger that the priorities of the funders will distort the work.
So, in an ideal world, funding would operate in a manner analogous to free software itself - totally decentralized, with funding coming from individuals, and with an absolute minimum of extra layers of management and administration.
I've been thinking about how to do this. At the core of my idea is a cryptographically sound mechanism for identifying the members of various groups, for example, legitimate free software developers. My idea is based on certification by peers, and also has the property that it's very difficult to attack, i.e. if some imposters managed to get certified, they'd be able to do only a very limited amount of damage.
The link above talks mostly about the techinical issues. However, the social ones are even more important. Christopher Browne has written a proposal that goes into much more detail at this level - you might have seen his letter to lwn.net a couple of weeks ago.
My ideas are too rough and unfinished right now to do anything concrete. When I get the prototype running, I'll try to write up the ideas in less drafty form.
Absolutely. The Gnome canvas started out in life as a pretty straightforward adaptation of the Tk Canvas. I'm not sure exactly where it showed up first, but it wasn't invented by Borland either:)
What's cool about this one is its really smooth integration into the Gtk+ object model, and the antialiased rendering back-end.
Slashdot Mirror
I've been looking at digital cameras, hoping that they will soon become a viable alternative to 35mm photography. I think these people are some of the worst offenders on stretching specs.
Most egregiously, they count the RGB sensors as three separate pixels. By this logic, the laptop I'm typing on has 3072 x 768 pixels; pretty impressive, hm? On the very best of the digital cameras (the Nikon 950), the effective number of pixels (measured using resolution targets) is about half the claimed spec, and even then the image suffers from moire, chromatic aberration, and other artifacts.
What really opened my eyes was looking at Sound Vision's camera, which is only 800 x 600 pixels, but blows away the "megapixel" cameras in total image quality. Unfortunately, because this camera has to take three separate shots through three separate filters (R, G, and B), it's only useful for a limited range of work, so it's foundering.
As if this weren't bad enough, Kodak came out with a digital camera with about a million "pixels", but marketed it as about 1.5M, because they estimated that it delivered quality slightly superior to the 1.3Mpix cameras they were competing with. Can you imagine printers competing on this basis? At least dpi claims have tended to be fairly solid (although I'm more than a bit suspicious over Epson's 1440).
Caveat emptor, I guess.
Apparently, all 17 tracks of the soundtrack were leaked last night in .mp3 format. The original server got shut down fairly quickly, alas, so you'll have to hunt them down.
The release of these tracks probably makes the RIAA very unhappy, but I'm not at all convinced of it. It certainly makes me want to go out and buy the soundtrack when it becomes available.
The Gnome/KDE "war" gives us the opportunity to think about competing systems in a totally new way. A lot of people think about it in essentially the same terms as Win vs Mac, but I think this is a narrow view.
There are basically two ways of getting a unified system. You can start with a design for how things Should Be Done, and reject anything that doesn't meet the design. It's a good approach - the Mac has done this with great success. We laugh at newbies who try to put a Mac disk in a PC and expect to run the software. Should we?
The other way to do it is to work to make the pieces integrate well. And this, my friends, is more the Linux Way, if you ask me. We don't talk about NFS vs. Samba vs. Netatalk. You've got a heterogenous network? Run 'em all!
Now, to get KDE and Gnome to seamlessly integrate is quite a challenge, both technically and politically. But I have some hope that the two teams are willing and able to work on it, in a way that Microsoft and Apple never could.
Here's a specific example of what I have in mind. Both Gnome and KDE have some mechanism for "themes", ie the ability to configure the graphical look. What if there were a theme setting application that set the themes of both desktop environments, and so that they're consistent? Ultimately, a person might not need to know or care whether an app is KDE or Gnome - it will be a matter of developer preference.
Of course, this vision takes quite a bit of work. A bi-theme application is quite a bit harder than one for a single desktop. Work will no doubt be required to bring the theme systems in harmony. But I think all of this can and will happen.
Raph, a Gnome developer who supports KDE
I spoke to the reporter for about an hour on this story, and am not too surprised at how it turned out. I think he's missing some major points.
The basic premise, I think, is faulty - that because the GPL hasn't been tested in court, that the status of GPL software is somehow shaky. I think the reverse is actually true, that the free software community is so healthy and is so good at dispute resolution that it has been unnecessary to call in the lawyers.
Think of how many heated technical disputes there have been - should KGI be in the kernel? The Egcs split from Gcc. Gnome vs. KDE. Even the ncurses debacle. All of these have been handled without legal action, and some have been resolved quite nicely (way to go, Gnu compiler folks!).
Now I think it is inevitable that lawyers will come into the fray, especially as there is more and more money in free software. Sooner or later, somebody who's market share is being decimated by free software is going to try to throw a legal monkeywrench into the development process. Other legal threats are also possible.
But the main hypothetical of this article, that a company would flagrantly violate the GPL, seems to me to be outlandish. After all, a snapshot of the code is far from the most valuable part of a vital free software project. It's the knowledge, the community, and the stewardship of keeping the project that's going. Violating the GPL is the surest way of alienating that community and thereby abandoning the benefits from it.
The reporter asked me what I would do if a big company flagrantly violated the GPL of a project I was involved in. My response was that, after making sure that they were in fact in the wrong, and that they had been contacted and turned down the chance to set things right, I wouldn't call a lawyer, I'd post to Slashdot! And I think that would be far more effective. No company wants that kind of bad publicity.
In summary, I think there's something wonderful about the culture of free software that's allowed it to resist the influx of lawyers. I have hope that it can continue to do so.
P.S. I was quoted as "Raph Levien... who develops GIMP". I'm proud to be a part of the large and diverse Gimp development team, but I do want to point out I'm only responsible for a small fraction of the code that's in there.
Not only that, but the "future projects" page suffers from the dreaded question mark syndrome. Seems to me there's a deeper meaning in that :)
Real software usability goes deeper than just interactions with GUI dialogs and so on. For experts, Linux is much more usable than the consumer OS's because it is much more stable, more transparent (less things are hidden under the candy shell of the GUI), and has a broader collection of powerful tools. The challenge is going to be preserving this kind of usability while also making Linux more accessible to non-expert users.
One argument that's often made is that Linux suits the needs of expert users because it was designed by expert users. Since we are people who don't mind learning how things really work, and prefer the tools to be powerful once we do learn them, that's reflected in what we build. The argument usually goes on to say that since we don't want pretty but shallow, easy to learn but limited tools, we will never end up building these things for Linux novices.
This argument misses one important point, in my opinion. Even if you accept that the intellectual challenge of building usable software isn't by itself enough to keep the effort going, this argument pretty much assumes that the world is split up into hacker types and lots of isolated people who don't understand their computers. But this is not the full story. Many, many Linux people are sysadmins for a large number of not-so-computer-savvy users. Let me tell you something, Linux people in Windows sysadmin jobs hate having to do several fresh reinstalls of Windows per day per few hundred machines just because the registry gets wedged and there's no way to figure out how to fix it. Many of them would like nothing better than to have Linux become a viable desktop system so they'd be able to at least work with systems they don't hate.
It may well be that these hardy souls turn out to be the vast army that works to make free software usable. Once Linux starts going into the desktop in sysadminned environments, the channels are in place to collect user feedback, and also to do something about it. If such-and-such feature is confusing to users, then the admins will hear about it. It's probably easier in many cases to just fix it than keep dealing with the problem reports, and certainly a hell of a lot more fun.
Don't underestimate the dramatic strides already made in usability by the Linux community. When I first started working with Linux about six years ago, the usual way to install new software was to check the README, edit the Makefile, more often than not fix a few #includes or function prototypes, then run a series of make commands. These days we have RPM packages and so on, but we also have ./configure; make. To me, the autoconf system is a classic example of "deep usability" as opposed to the surface kind.
In summary, I think we're just going to keep on going until we get there.
Both of you have done great things for the community, and it's laudable to have differing points of view. But the bickering and personal attacks don't seem to be very helpful.
To quote Tim May about some flame-fest on cypherpunks, you two should just have sex and get it over with.
No.
I have little doubt that many people experience real improvements in typing speed and so on with Dvorak. I also have little doubt that winners of typing contests get an edge from the Dvorak layout. But it only takes a slight edge to win - how much real performance advantage do Speedos really make for swimmers? All Olympic swimmers wear them, but for recreational swimming, the difference is lost in the noise.
I think that the win that people get from learning Dvorak is that they are forced to spend time learning to type correctly. I (and many other hackers I know) have a very sloppy keying style, including moving the hands arounnd and using whichever finger is closest at the time. When I learned Dvorak, I tried to learn it right, and it wasn't possible to go back to being sloppy just out of habit, because then you hit the wrong keys (or, in Dvorak, yd. ,prbi t.fo). Training for speed typing would probably be just as effective, but who's motivated to do that?
The irony is that if Dvorak had taken over in the early days, most present-day hackers would get a similar benefit from learning Qwerty :)
The main reason I went back is that I'm often having to deal with other keyboards that haven't been remapped. The cognitive dissonance of having to go back and forth between the two layouts just wasn't worth it, and almost certainly decreased my total performance, even though the burst performance may have been higher when I got into the Dvorak "flow."
The reasoning in the editorial is pretty bogus, though. Just because the value of Dvorak doesn't exceed the cost of retraining does not imply that there's no economic lock-in effect - quite the contrary. It's only if the benefit were exactly zero that this would be the case. The authors have a point that the benefit of Dvorak is not as great as sometimes assumed, but that's not at all the same as claiming it's zero.
Raph, who's glad not to be locked in to either Speedos or swim trunks ;)
There's a lot of interesting things out there. In particular, I think XML and DOM could be the basis for a very good component framework in which powerful components would be easy to write, and would integrate nicely without a lot of hassle. I'm looking at RDF as a piece of this.
But, as far as I can tell, the problem that RDF solves is a bit different than the one mentioned in this article. RDF is a way of representing documents as graph structures, allowing individual files to contain both local and external pieces without everything getting tangled up.
The problem of representing metadata unambiguously is a tricky one, but is not yet solved. The RDF spec presents an interesting outline about how this might be done, but it doesn't quite tell me what I need to do to get my own Web pages to be correctly meta'ed. If I were a library, then the Dublin Core would start to give me the specific markup I needed, but that's just for libraries. What do I use do as metadata for my free software efforts?
It seems like the combination of XML plus XML-NameSpaces plus Dublin Core plus all the other recommendations, specifications, and standards analogous to the Dublin Core but for domains other than libraries might cohere into a workable metadata system for the Web, but on the other hand, the complexity and fuzziness of specification could very easily prevent the beast from flying.
When you're dealing with software, precise specification is key. Some metadata standards have succeeded pretty well in this regard - take MIME content types, for example. If you have a JPEG image, you know that the content type should be "image/jpeg". But the XML crew hasn't even managed a consistent namespace name for HTML 4.0 (I've seen "urn:w3-org-ns:HTML", "http://www.w3.org/TR/REC-html40" and others).
For those hoping for a more technical discussion of RDF, I recommend the Mozilla page on RDF and of course the specification itself.
I have a friend who just lost his trademark because he didn't do a USPTO search, and is regretting it. This time around, we searched pretty damn thoroughly.
I like the idea of having a scale.
I might also suggest that the average is computed with some dummy neutral score added in. That way, if a single person gives a +10 score, it won't go to the top of the list. If lots of people give scores, then you get a true average.
Mathematically, the system I'm proposing is somewhere between the current +1/-1 system and the idea of a simple average.
I really look forward to seeing if Rob can solve the moderation problem. Lots of attempts have failed before, but on the other hand Slashdot has a lot of things going for it that previous systems lacked.
Anyone else noticed the similarity between the current contents of www.linux.com and www.transmeta.com? I think this is evidence of a shadowy Linux conspiracy. My guess is that their goal is nothing short of world domination. Beware!
Just to interject a bit of fact here, libart is definitely not proprietary, nor does it belong in any way to RedHat (though I do realize that the R and H in my name might be confusing :).
In point of fact, I've been in e-mail communication with Roberto Alsina, a KDE developer, about the possbility of using libart to make an antialiased version of Qt's QPaint widget. Since the current libart is entirely LGPL, there are no licensing problems. I personally would love to see this happen. The more wins for libart, the better chance I have making some money licensing libart into the commercial world.
It actually looks pretty decent at 256 colors. We use a 6x6x6 color cube. There are some dithering patterns, but these are pretty much unavoidable.
This is work in progress - the antialiased text integration has not been done yet, even though I do have code for smooth antialiased text rendering from type1 outlines. See this screenshot for a "technology demo."
We're looking into that. Of course, this work will be useful even on non-Xfree systems. It can also do alpha-compositing of text and graphics together, which Xfree probably can't do.
I personally am not that happy with the idea of taxpayer funding. No matter what the source of funding, there's the danger that the priorities of the funders will distort the work.
So, in an ideal world, funding would operate in a manner analogous to free software itself - totally decentralized, with funding coming from individuals, and with an absolute minimum of extra layers of management and administration.
I've been thinking about how to do this. At the core of my idea is a cryptographically sound mechanism for identifying the members of various groups, for example, legitimate free software developers. My idea is based on certification by peers, and also has the property that it's very difficult to attack, i.e. if some imposters managed to get certified, they'd be able to do only a very limited amount of damage.
The link above talks mostly about the techinical issues. However, the social ones are even more important. Christopher Browne has written a proposal that goes into much more detail at this level - you might have seen his letter to lwn.net a couple of weeks ago.
My ideas are too rough and unfinished right now to do anything concrete. When I get the prototype running, I'll try to write up the ideas in less drafty form.
What's cool about this one is its really smooth integration into the Gtk+ object model, and the antialiased rendering back-end.