Done, indeed it's a better design now! I've removed the NBCairo class, reified almost all Cairo objects as a subclass of NBCairoObject. I've also added CairoText, for easier drawing of text using Cairo Toy Text API. (and CairoLineCap, CairoLineJoin ) All the examples work again, also the new ones. As soon as squeaksource is up again i'll commit. Fernando pd: I will apply the same refactoring to NBPango also. I still have to answer your questions regarding the use of Pango. On Mon, Dec 12, 2011 at 6:44 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

On Dec 12, 2011, at 5:35 PM, Igor Stasenko wrote:

...

On 12 December 2011 17:16, Fernando Olivero <fernando.olivero@usi.ch> wrote:

...

ok, i see your point. I will refactor back to Javier's approach. My rationale was to reify the Cairo library as it is, luckily all the other examples work.

Well, it makes sense to do things like that, when you want a fast and dirty working stuff. But a good wrapping makes a lot of difference: there is no need to indicate that you using a library through 'self cairo' everywhere. It is just an indirection without any benefit.

Wrapper classes and their instances should provide a required functionality through well defined protocols, and then from user's standpoint it is really makes no difference who implements them. That's why we need Athens.

Indeed we do want to have cairo dependencies inside our system just encapsulated in their respective canvases.

...

...

If i add the shared pool NBCairoTypes to the NBCairo then NativeBoost automatically associates the type? Because i've been putting directly "int". Would be nice to have a couple of examples of NB (whenever the time is enough for you guys, i know you are busy)

Yes, but these examples were written specifically to show how to wrap a library in object-oriented way  :) Look at pharo by example book [1], there you can find an explanation how to use shared pools. Of course it is far from complete, but my opinion that your refactoring gives a bad example to future developers. They should think in terms of objects and place callouts in corresponding classes with nicely formed protocol(s).

I am looking forward for you to come, so i can explain things more directly and easier :)

[1] https://gforge.inria.fr/scm/viewvc.php/*checkout*/PharoByExampleTwo-Eng/Alie...

...

thanks for the feedback, Fernando

On Mon, Dec 12, 2011 at 5:05 PM, Igor Stasenko <siguctua@gmail.com> wrote:

...

CairoSamplePrograms>>rectangleAndText does not works, because it uses a following method:

NBCairo>>selectFont: aFamily slant: slant weight: aWeight on: aNBCairoContext        <primitive: #primitiveNativeCall module: #NativeBoostPlugin>        ^self call: #(void cairo_select_font_face (NBCairoContext aNBCairoContext,                                                         String aFamily,

cairo_font_slant_t slant,

cairo_font_weight_t aWeight) )

and during code generation it barks that it unable to resolve 'cairo_font_slant_t'  type. Because NBCairo class does not includes a corresponding shared pool (NBCairoTypes).

Also, Fernando, i don't like that you put everything into a single class (NBCairo). This is wrong, not object-oriented. The original organization made by Javier was much more closer to my tastes.

This approach to wrapping a library is too mechanical. It is much better to place calls at proper place(s) in proper classes, rather than putting everything into a single one. Which means that in this way you are at least 1 message send farther from real function call. But in your case its not even that..

NBCairoPattern>>status        ^ self cairo patternStatusOf: self

cairo        ^ NBCairo default

so , it is 2 extra message sends, instead of direct call to foreign function!

-- Best regards, Igor Stasenko.

-- Best regards, Igor Stasenko.