I was discussing with Eric on the silc channel about integrating the DrawKit (www.apptree.net/drawkit.htm) code base into EtoileUI, which we had both thought about doing. Eric told me that some of the functionality (grouping and layers, styling etc, as I understood it) is already a part of EtoileUI, so only certain parts of DrawKit should be ported.
We also talked about the need for a CoreGraphics implementation and Eric told me about the half-finished Opal implementation, which I check out from the repository. I managed to compile most of it under OSX (after installing Cairo using macports), although for some reason cairo's font support was not linked correctly. But then I saw that Quartz is actually used very little in DrawKit, except for filter, which are nice but not a core feature. DK relies mostly on NSBezierPath which is implemented in GNUstep. The gs implementation uses post script to draw (using functions in PSOperators.h), but I've seen talk on email lists about other back-ends. Anyone know anything about this? So, from what it looks like, we might not need a CoreGraphics implementation after all, although it would surely be useful, if we want flexible gradients and maybe other things. What do people think? How interesting is a CoreGraphics implementation? I could give it a shot, although I'm not dying to implement all those CGBitmapContext methods. In any case, wouldn't it be great if Etoile had really strong vector drawing support throughout? Personally, I think that gui:s and everything else in the world should be built using vector graphics as much as possible. /F _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
