On Thu, 2006-07-06 at 15:24 +0200, Juerg Lehni wrote: > 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)? That's the idea, yes. Switching toolkits is pretty easy. > Of corse, if more than one Toolkit is available, the normal > java.awt.headless switch should be used to activate Headless mode. Right. > 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. That's an interesting question, actually. I don't really know. Obviously we should try to avoid X-specific dependencies wherever possible. > But then there was gnu_java_awt_peer_gtk_ComponentGraphics.c, in > which the fix will not be that easy: [..] > 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. Hmm.. the thing here is that the code gets the X pixmap associated with the component, and uses the X-surface-drawing backend of Cairo to draw to that. I'm not 100% sure of how to adress this, but you/we will probably need a replacement for that. Most likely using the Quartz/Win32 backends for that. (Although I don't know how you create one of those for a GTK component under Windows/OS X, but it should be possible somehow.) On the plus side, it's relatively little code since most of the work is done by the abstract CairoGraphics class. Another, related, issue is VolatileImage, which maps to an X pixmap, and also uses ComponentGraphics (being an X surface). That'll need to map to some other native structure (on which Cairo can draw). So, obviously and unfortunately, it's not just a matter of replacing a few X class with GTK equivalents. But on the other hand, I think that's the most of it, and luckily it's fairly straightforward to do your own implementation extending CairoGraphics for the various backends. (The rest of you can thank me here for doing that big refactoring separating the Cairo code from the GTK code from the X code ;)) /Sven
