Random list of AWT TODOs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
>
>



[Index of Archives]     [Linux Kernel]     [Linux Cryptography]     [Fedora]     [Fedora Directory]     [Red Hat Development]

  Powered by Linux