On 21 December 2011 10:58, Stéphane Ducasse <[email protected]> wrote: > >> You are using the last approach, using getData, nice that is already >> implemented. >> >> Yes, i will move to Athens now. Up to now i've been playing with >> NBCairo, to render all the Gaucho shapes. >> >> I see that all NBCairo classes are replicated in Athens, > > not replicated :) > In fact Athens design supports well the decomposition of Cairo :) > >> NBCairoSurface=AthensCairoSurface, AthenCairoCanvas = NBCairoContext. >> Does it make sense to refactor Athens to use NBCairo? > > No just gets inspiration. > >> Currently there >> are two ways of interfacing with Cairo, maybe Athens should just reuse >> NBCairo. > > It depends what you call reuse. But for us NBCairo should disappear and just > have Athens. > >> Athens should simply be "an adapter" from the Athens API, to the >> actual Cairo wrapper (NBCairo). > > Why? because we can call directly the cairo library >
Athens defines a roles, like surface, canvas, paints, shapes and transformation and protocols for them. The concrete implementation (or classes) are not that important, since you should rely on protocol(s) of objects with designated roles. In this way a different backend may serve as well as any other for your application. I hope it will also teach people to not use directly classes everywhere, but instead use factory messages available from factory objects (which can be asked for creating a new object of certain properties), instead of using direct class name(s). NBCairo originally created by Javier as an example how to write binding of external library using NativeBoost. There was no any plans concerning developing NBCairo beyond serving as a simple example. I think it is more important to have a framework with own balanced and well designed API for vector graphics, not tied to some concrete library (like that we can switch the backend at any moment, while keep everything running). -- Best regards, Igor Stasenko.
