On Thu, 2006-07-06 at 20:01 +0200, Sven de Marothy wrote: > On Thu, 2006-07-06 at 15:24 +0200, Juerg Lehni wrote: > > > 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 ;)) Tack så mycket! (Thanks a whole lot) :-) Another interesting case is running on GTK-DirectFB. Does someone have an analogous perspective to share about that one? Thanks a lot, -- Philippe Laporte
