On Sat, Jul 25, 2009 at 5:20 AM, Felix Holmgren<felix.holmg...@gmail.com> wrote: > 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?
Nah, it doesn't use postscript, really. It simply use those PSOperators functions, but they then are implemented by each backend. AFAIK, all NSBezierPath operations should be working fine at least for the libart backend and the cairo backend (I vaguely remember that the xlib backend had some trouble with some operations though, but this might have been fixed). Drawing gradients (or at least some way of drawing gradients) is implemented in the libart backend, it should also be implemented with the cairo backend (and if not it shouldn't be difficult to add). > 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. A CoreGraphics implementation might be interesting when porting OSX programs. In the case of DrawKit, as you say it's using NSBezierPath, this wouldn't be needed. > 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. I'm not sure I follow you -- GNUstep gui is already vector-based. If you mean having a vector drawing editor then yes :) -- Nicolas Roard "I love deadlines. I like the whooshing sound they make as they fly by." -- Douglas Adams _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
