Hi Sven,
I have a question regarding the Headless Toolkit.
Will it be possible to decide which one to use both at compile time
and runtime? I mean, will it be possible to compile Classpath to only
compile and use the Headless Toolkit, for environments where GTK is
not supported well (e.g. OS X without X11)?
Of corse, if more than one Toolkit is available, the normal
java.awt.headless switch should be used to activate Headless mode.
Another question: Will the GTK backend continue to depend on X11 as
well? I tried to compile the current version of AWT with the OS X /
Quartz implementations of GTK and Cairo, and realized there are quite
a few dependencies on X11 stuff in the AWT sources. Some examples:
In gnu_java_awt_peer_gtk_CairoSurface.c
#include <cairo-xlib.h>
#include <gdk/gdkx.h>
I replaced these with
#include <cairo-quartz.h>
#include <gdk/gdk.h>
and it compiled correctly.
But then there was gnu_java_awt_peer_gtk_ComponentGraphics.c, in
which the fix will not be that easy:
#include <X11/extensions/Xrender.h>
The code then has various dependencies on X11 that will not run in
such a Quartz environment. I'm not into GTK on Windows, but I doubt
it will work there either.
I was wondering if these dependencies can be remove / replaced by
code that's only depending on GTK.
Jürg
Am 01.07.2006 um 01:09 schrieb Sven de Marothy:
Hello all.
I thought I'd just post my laundry-list of TODOs here, in case someone
else wanted to jump in and help out.
awt.font
* Arabic shaping.
Arabic text is currently written in correct order (right-to-left) but
the characters need joining. This job is to be done by
FreetypeGlyphvector. For details on the algorithm, see Chapter 8.2 of
the Unicode standard.
(http://www.unicode.org/versions/Unicode4.0.0/ch08.pdf)
This isn't that hard to do, but certain character pairs will end up
represented as one glyph. The glyphvector impl needs some small
modifications to handle this. (TextLayout *should* be able to handle
this already, however this is not well tested).
* Devanagari & friends.
Similarily, the south-Asian scripts require some more work to be
done in
order to convert to glyphs. This is detailed in chapter 9 of the
standard. (http://www.unicode.org/versions/Unicode4.0.0/ch09.pdf)
It's a bit more work than the Arabic case, but mostly it'd be
helpful if
someone who knows the language did this.
* Finish TextLayout - not too much work left here, but you can see the
methods in the JAPI scores. More testing and bug-hunting is of course
welcome too.
awt.image
* Make CairoSurface extend Raster and implement some interface for
BufferedImage to get Cairo implementations of Raster.
So that creating an ARGB BufferedImage will create a surface Cairo can
draw directly and also draw to. Other BufferedImage types can keep a
copy of themselves as this kind of raster and copy that data back
to the
original raster when the user does a BufferedImage.getData().
BufferedImageGraphics can then be dropped.
* The awt.image code needs to be checked and tested closely. There's a
lot of bugs in there and some stuff which is plain wrong. (E.g.
calls to
ColorSpace methods with bad parameters).
ImageIO
* Still needs a lot of work. But getting awt.image working is
probably a
prerequisite for this. A GIF plugin is now available, and a PNG one
for
writing and reading is nearing completion. JPEG is still missing.
We can never have enough plugins! If anyone wants there's all kinds of
obscure formats left to support. TIFF, PICT, Targa, ICO, CUR,
Sunraster,
XBM, XPM, PCX, Amiga IFF. Whatever you feel like (some of these are
really simple).
If you're a newbie and can't be bothered to learn the whole IIO
framework just to contribute a simple plugin, if you want, you can
always just contribute something along the lines of:
static BufferedImage loadImage( InputStream in )
and someone more experienced around here can wrap that with the
necessary plugin code.
Headless
We need a headless toolkit which getDefaultToolkit() can return.
(which can do the job of throwing the HeadlessExceptions, not as
now in
the AWT code). At least right now I've got plans for a Cairo
+Freetype-based one, which'll allow us to reuse existing code.
This will require:
* The actual toolkit, which should be fairly simple to implement.
(Most peers throw HeadlessException, except "lightweight" peers like
Canvas and Panel which get dummy implementations. createImage()
returns
a BufferedImage or uses ImageIO, and so on.
* A Freetype-based Font peer. (Not too much work) This can pretty much
be used as-is with the existing GlyphVector implementation and by
extension all text rendering. (This peer can then be reused by the GTK
peers for Font.createFont).
* A few modifications to the build to accomodate all that.
awt.print
* Page margins are off.
* Gradients are written as Level-3 PostScript, which isn't really
useful
for most people in the real-world who don't have level-3 printers. (I
was hoping CUPS RIP-filter would take care of it, but it doesn't
seem so
on my machine/printer at least)
* Some stuff remains to be implemented, e.g. compositing (which is
indeed a long-standing problem with anyone trying to generate sane
PostScript)
So, anyone want to help out, let us know!
/Sven
