Hi Felix, Le 25 juil. 09 à 06:20, Felix Holmgren a écrit :
> 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. Yes. In fact, I took a look at DrawKit two years ago and I have been following it since then. I initially thought about porting it to GNUstep at the same time I started EtoileUI. In the end, I found that that DrawKit was more complex than it ought to be and woun't fit well with EtoileUI which has a broader goal (compound document support, UI builder, core object integration etc.) More important the license appears to be BSD, but doesn't seem to be since there is this extra clause: 'Furthermore, DrawKit is licensed under these conditions FREE OF CHARGE for all non-commercial and educational use. For commercial use, a FEE may be due. Please contact the author for details. Alternative licensing may be negotiated in individual cases for commercial, fee-paying users. Please note that any fee is individually negotiable, and may be waived in certain circumstances.' This means no DrawKit code be reused. Extending EtoileUI (or a new framework sitting on top of it) with vector graphics related features such as boolean operations on paths/ shapes, text on a path, interactive path editing with control points etc. still remains to be implemented though. > 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? It would be useful mainly for compatibility with Mac OS X and new Cocoa frameworks. It's also a clean and consistent low-level graphics API. GNUstep doesn't really have an equivalent consistent and well organized API, so it could be nice to have GNUstep uses it. imo it can help to make GNUstep code more consistent in the long run and ensure the Cocoa compatibility is optimal. With a CoreGraphics implementation, CoreText can also be implemented. CoreText is a new Mac OS X 10.5 library for font handling and text layout. Since the GNUstep text system would benefit to be cleaned, it might interesting to use this API as a new base. > 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. Yes :-) I fully agree. From a low-level viewpoint it is already the case as Nicolas pointed it. From a high-level viewpoint, the driving idea behind EtoileUI is to treat everything on screen as a single compound document. Exactly as if the whole environment was an Inkscape/ Illustrator/Flash document and running inside such an application. The traditional approach is to build a graphics editor framework on top of the UI toolkit (AppKit in our case). With EtoileUI the graphics editor framework is put under the UI toolkit and UI building becomes a subcase of graphics editing. However EtoileUI won't provide a full-blown vector graphics editor out of the box and it will just provide a small core that can be extended. We'll probably have a additional vector graphics editing framework that provide the missing pieces to build a full-featured vector graphics editor. Cheers, Quentin. _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
