native boost is the best thing since COGVM

> A taste of what will be available: rendering the same GLabel (the
> gaucho equivalent to StringMorph), scaling the CairoCanvas.
>
> Pesudo Code:
>
> "create a label"
> label := GLabel on : 'hello Pango-Cairo'.
>
> "draw it on the canvas"
> label drawOn: canvas.
>
> "scale the canvas"
> canvas translateBy: aDelta ; scaleBy: aScale.
>
> "draw it on the canvas"
> label drawOn: canvas.
>
> "repeat"
>
>
>
>
> On Sun, Dec 11, 2011 at 7:43 PM, Javier Pimás
> <[hidden email]> wrote:
>> Cooool!!!
>>
>> On 12/11/11, Fernando Olivero <[hidden email]> wrote:
>>> I was able to create the binding to Pango using NB.
>>>
>>> The ultimate goal is to provide a cleaner implementation of "text" widgets.
>>>
>>> Thanks Igor !
>>>
>>> Fernando
>>>
>>
>>
>> --
>> Lic. Javier Pimás
>> Ciudad de Buenos Aires

> 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.
>

> thanks for the feedback,
> Fernando
>
>
>
> On Mon, Dec 12, 2011 at 5:05 PM, Igor Stasenko <[hidden email]> 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.
>>
>

> A taste of what will be available: rendering the same GLabel (the
> gaucho equivalent to StringMorph), scaling the CairoCanvas.
>
> Pesudo Code:
>
> "create a label"
> label := GLabel on : 'hello Pango-Cairo'.
>
> "draw it on the canvas"
> label drawOn: canvas.
>
> "scale the canvas"
> canvas translateBy: aDelta ; scaleBy: aScale.
>
> "draw it on the canvas"
> label drawOn: canvas.
>
> "repeat"

> On 12 December 2011 17:16, Fernando Olivero <[hidden email]> 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.

>> 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/Alien/alien.pdf?root=pharobooks
>
>> thanks for the feedback,
>> Fernando
>>
>>
>>
>> On Mon, Dec 12, 2011 at 5:05 PM, Igor Stasenko <[hidden email]> 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.
>

>
> On Dec 12, 2011, at 5:35 PM, Igor Stasenko wrote:
>
>> On 12 December 2011 17:16, Fernando Olivero <[hidden email]> 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/Alien/alien.pdf?root=pharobooks
>>
>>> thanks for the feedback,
>>> Fernando
>>>
>>>
>>>
>>> On Mon, Dec 12, 2011 at 5:05 PM, Igor Stasenko <[hidden email]> 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.
>>
>

> Stef
>
>
>> A taste of what will be available: rendering the same GLabel (the
>> gaucho equivalent to StringMorph), scaling the CairoCanvas.
>>
>> Pesudo Code:
>>
>> "create a label"
>> label := GLabel on : 'hello Pango-Cairo'.
>>
>> "draw it on the canvas"
>> label drawOn: canvas.
>>
>> "scale the canvas"
>> canvas translateBy: aDelta ; scaleBy: aScale.
>>
>> "draw it on the canvas"
>> label drawOn: canvas.
>>
>> "repeat"
>