[ANN] 10252

> Standard Squeak uses original menu pin form.
> Tweaked appearance of drop lists for Watery 2 as an interim measure.
> Fixed positioning of drop list pop-up-list to deal with transforms (no
> rotation though ;-) ) (thanks Alain)
>
> Removed "revert" option in patch browser for MC 1.0 compatability.
> Handle missing remote definition when selecting next conflict.
>
> Stef
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> 2009/3/13 Stéphane Ducasse <[hidden email]>:
>> Added BoundedGradientFillStyle.
>
> can to elaborate , what is it? :)
>
> We duscussed the fill styles with Gary a while ago, and the result of
> a discussion is to make fill styles to know what they need to do to
> fill the given shape i.e. fill style could be seen as a function:
> f(shape, canvas)
>
> and, to use a fill style, in general form, you simply should use:
> myfillStyle fill: someShape on: canvas.
>
> This concept were introduced into Polymorph, and as first proof of it,
> Gary implemented a composite fill styles.
> But it's far from complete. In ideal, i'd like to get rid of many
> 'isXXXFill', like #isGradientFill and others and remove any code which
> relying on fill style properties - instead it should always delegate
> the responsibility from filling a shape to a fill style object.
>
> This approach , also opens a new questions:
> - how do we treat a morph. Should morph define own shape? Or shape is
> something that should be determined procedurally, and morph could
> contain/use as many shapes as it wants to for representing itself on
> canvas?
> I am far from thinking that morph's shape is rectangular (but there
> are many aspects in morphic, assuming it is rectangular - such as
> #fullBounds or #bounds), as well as i don't think that making morph
> === shape is a good choice.
>
>> Standard Squeak uses original menu pin form.
>> Tweaked appearance of drop lists for Watery 2 as an interim measure.
>> Fixed positioning of drop list pop-up-list to deal with transforms  
>> (no
>> rotation though ;-) ) (thanks Alain)
>>
>> Removed "revert" option in patch browser for MC 1.0 compatability.
>> Handle missing remote definition when selecting next conflict.
>>
>> Stef
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> stef
> On Mar 14, 2009, at 2:15 AM, Igor Stasenko wrote:
>
>> 2009/3/13 Stéphane Ducasse <[hidden email]>:
>>> Added BoundedGradientFillStyle.
>>
>> can to elaborate , what is it? :)
>>
>> We duscussed the fill styles with Gary a while ago, and the result of
>> a discussion is to make fill styles to know what they need to do to
>> fill the given shape i.e. fill style could be seen as a function:
>> f(shape, canvas)
>>
>> and, to use a fill style, in general form, you simply should use:
>> myfillStyle fill: someShape on: canvas.
>>
>> This concept were introduced into Polymorph, and as first proof of it,
>> Gary implemented a composite fill styles.
>> But it's far from complete. In ideal, i'd like to get rid of many
>> 'isXXXFill', like #isGradientFill and others and remove any code which
>> relying on fill style properties - instead it should always delegate
>> the responsibility from filling a shape to a fill style object.
>>
>> This approach , also opens a new questions:
>> - how do we treat a morph. Should morph define own shape? Or shape is
>> something that should be determined procedurally, and morph could
>> contain/use as many shapes as it wants to for representing itself on
>> canvas?
>> I am far from thinking that morph's shape is rectangular (but there
>> are many aspects in morphic, assuming it is rectangular - such as
>> #fullBounds or #bounds), as well as i don't think that making morph
>> === shape is a good choice.
>>
>>> Standard Squeak uses original menu pin form.
>>> Tweaked appearance of drop lists for Watery 2 as an interim measure.
>>> Fixed positioning of drop list pop-up-list to deal with transforms
>>> (no
>>> rotation though ;-) ) (thanks Alain)
>>>
>>> Removed "revert" option in patch browser for MC 1.0 compatability.
>>> Handle missing remote definition when selecting next conflict.
>>>
>>> Stef
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> 2009/3/14 Stéphane Ducasse <[hidden email]>:
>> I will let gary reply and rollback if necessary. or even better
>> integrate next fixes :)
>> I thought it was ready for integration.
>>
> I didn't said its not ready..
> I just wanted to point out, that it is half-done, in the way how i see
> it should be done.
> It works, of course, but not so elegant as it should be :)
>
>> stef
>> On Mar 14, 2009, at 2:15 AM, Igor Stasenko wrote:
>>
>>> 2009/3/13 Stéphane Ducasse <[hidden email]>:
>>>> Added BoundedGradientFillStyle.
>>>
>>> can to elaborate , what is it? :)
>>>
>>> We duscussed the fill styles with Gary a while ago, and the result of
>>> a discussion is to make fill styles to know what they need to do to
>>> fill the given shape i.e. fill style could be seen as a function:
>>> f(shape, canvas)
>>>

>>> and, to use a fill style, in general form, you simply should use:
>>> myfillStyle fill: someShape on: canvas.
>>>
>>> This concept were introduced into Polymorph, and as first proof of it,
>>> Gary implemented a composite fill styles.
>>> But it's far from complete. In ideal, i'd like to get rid of many
>>> 'isXXXFill', like #isGradientFill and others and remove any code which
>>> relying on fill style properties - instead it should always delegate
>>> the responsibility from filling a shape to a fill style object.
>>>
>>> This approach , also opens a new questions:
>>> - how do we treat a morph. Should morph define own shape? Or shape is
>>> something that should be determined procedurally, and morph could
>>> contain/use as many shapes as it wants to for representing itself on
>>> canvas?
>>> I am far from thinking that morph's shape is rectangular (but there
>>> are many aspects in morphic, assuming it is rectangular - such as
>>> #fullBounds or #bounds), as well as i don't think that making morph
>>> === shape is a good choice.
>>>
>>>> Standard Squeak uses original menu pin form.
>>>> Tweaked appearance of drop lists for Watery 2 as an interim measure.
>>>> Fixed positioning of drop list pop-up-list to deal with transforms
>>>> (no
>>>> rotation though ;-) ) (thanks Alain)
>>>>
>>>> Removed "revert" option in patch browser for MC 1.0 compatability.
>>>> Handle missing remote definition when selecting next conflict.
>>>>
>>>> Stef
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

> 2009/3/14 Igor Stasenko <[hidden email]>:
>> 2009/3/14 Stéphane Ducasse <[hidden email]>:
>>> I will let gary reply and rollback if necessary. or even better
>>> integrate next fixes :)
>>> I thought it was ready for integration.
>>>
>> I didn't said its not ready..
>> I just wanted to point out, that it is half-done, in the way how i see
>> it should be done.
>> It works, of course, but not so elegant as it should be :)
>>
>>> stef
>>> On Mar 14, 2009, at 2:15 AM, Igor Stasenko wrote:
>>>
>>>> 2009/3/13 Stéphane Ducasse <[hidden email]>:
>>>>> Added BoundedGradientFillStyle.
>>>>
>>>> can to elaborate , what is it? :)
>>>>
>>>> We duscussed the fill styles with Gary a while ago, and the result of
>>>> a discussion is to make fill styles to know what they need to do to
>>>> fill the given shape i.e. fill style could be seen as a function:
>>>> f(shape, canvas)
>>>>
>
> going further with that, all drawings (not only fills) on canvas could
> be represented by such function
> f(shape, canvas)
> but it would require a deep refactorings in bitblt/morphic engine to
> do such unification.
>
> With such approach, it would be easy to introduce a new fill styles,
> such as bevel/emboss, blur , etc.
> While old fillstyles implementation is quite limited, because
> fillstyle used as a dumb state holder and drawing engine performs
> different tests (isXXXX) to do the right thing.
>
>>>> and, to use a fill style, in general form, you simply should use:
>>>> myfillStyle fill: someShape on: canvas.
>>>>
>>>> This concept were introduced into Polymorph, and as first proof of it,
>>>> Gary implemented a composite fill styles.
>>>> But it's far from complete. In ideal, i'd like to get rid of many
>>>> 'isXXXFill', like #isGradientFill and others and remove any code which
>>>> relying on fill style properties - instead it should always delegate
>>>> the responsibility from filling a shape to a fill style object.
>>>>
>>>> This approach , also opens a new questions:
>>>> - how do we treat a morph. Should morph define own shape? Or shape is
>>>> something that should be determined procedurally, and morph could
>>>> contain/use as many shapes as it wants to for representing itself on
>>>> canvas?
>>>> I am far from thinking that morph's shape is rectangular (but there
>>>> are many aspects in morphic, assuming it is rectangular - such as
>>>> #fullBounds or #bounds), as well as i don't think that making morph
>>>> === shape is a good choice.
>>>>
>>>>> Standard Squeak uses original menu pin form.
>>>>> Tweaked appearance of drop lists for Watery 2 as an interim measure.
>>>>> Fixed positioning of drop list pop-up-list to deal with transforms
>>>>> (no
>>>>> rotation though ;-) ) (thanks Alain)
>>>>>
>>>>> Removed "revert" option in patch browser for MC 1.0 compatability.
>>>>> Handle missing remote definition when selecting next conflict.
>>>>>
>>>>> Stef
>>>>>
>>>>> _______________________________________________
>>>>> Pharo-project mailing list
>>>>> [hidden email]
>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Igor Stasenko AKA sig.
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 

> Sadly BitBlt and/or Balloon don't support much so we're stuck with
> GradientFills and rectangles for shapes (where the double-dispatched  
> "puting
> the behaviour in the fill style" is concerned, unless the low-level  
> shape
> drawing types are all dispatched)...
>
> As for the original question, BoundedGradientFillStyle simply allows  
> for an
> extent so that, as part of a composite, it can be limited to only  
> part of
> the drawing area. This makes it possible to make composites that have
> different corner images (for example) along with gradients for the  
> "stretchy
> bits" in between...
>
> In respect of the isXXX methods, these could be refactored properly  
> such
> that the morph informs its fillStyle of bounds changes. For simple  
> colours
> this would be effecitvely a no-op, gardients would adjust their  
> origin etc.
>
> Regards, Gary
>
> ----- Original Message -----
> From: "Igor Stasenko" <[hidden email]>
> To: <[hidden email]>
> Sent: Saturday, March 14, 2009 9:13 AM
> Subject: Re: [Pharo-project] [ANN] 10252
>
>
>> 2009/3/14 Igor Stasenko <[hidden email]>:
>>> 2009/3/14 Stéphane Ducasse <[hidden email]>:
>>>> I will let gary reply and rollback if necessary. or even better
>>>> integrate next fixes :)
>>>> I thought it was ready for integration.
>>>>
>>> I didn't said its not ready..
>>> I just wanted to point out, that it is half-done, in the way how i  
>>> see
>>> it should be done.
>>> It works, of course, but not so elegant as it should be :)
>>>
>>>> stef
>>>> On Mar 14, 2009, at 2:15 AM, Igor Stasenko wrote:
>>>>
>>>>> 2009/3/13 Stéphane Ducasse <[hidden email]>:
>>>>>> Added BoundedGradientFillStyle.
>>>>>
>>>>> can to elaborate , what is it? :)
>>>>>
>>>>> We duscussed the fill styles with Gary a while ago, and the  
>>>>> result of
>>>>> a discussion is to make fill styles to know what they need to do  
>>>>> to
>>>>> fill the given shape i.e. fill style could be seen as a function:
>>>>> f(shape, canvas)
>>>>>
>>
>> going further with that, all drawings (not only fills) on canvas  
>> could
>> be represented by such function
>> f(shape, canvas)
>> but it would require a deep refactorings in bitblt/morphic engine to
>> do such unification.
>>
>> With such approach, it would be easy to introduce a new fill styles,
>> such as bevel/emboss, blur , etc.
>> While old fillstyles implementation is quite limited, because
>> fillstyle used as a dumb state holder and drawing engine performs
>> different tests (isXXXX) to do the right thing.
>>
>>>>> and, to use a fill style, in general form, you simply should use:
>>>>> myfillStyle fill: someShape on: canvas.
>>>>>
>>>>> This concept were introduced into Polymorph, and as first proof  
>>>>> of it,
>>>>> Gary implemented a composite fill styles.
>>>>> But it's far from complete. In ideal, i'd like to get rid of many
>>>>> 'isXXXFill', like #isGradientFill and others and remove any code  
>>>>> which
>>>>> relying on fill style properties - instead it should always  
>>>>> delegate
>>>>> the responsibility from filling a shape to a fill style object.
>>>>>
>>>>> This approach , also opens a new questions:
>>>>> - how do we treat a morph. Should morph define own shape? Or  
>>>>> shape is
>>>>> something that should be determined procedurally, and morph could
>>>>> contain/use as many shapes as it wants to for representing  
>>>>> itself on
>>>>> canvas?
>>>>> I am far from thinking that morph's shape is rectangular (but  
>>>>> there
>>>>> are many aspects in morphic, assuming it is rectangular - such as
>>>>> #fullBounds or #bounds), as well as i don't think that making  
>>>>> morph
>>>>> === shape is a good choice.
>>>>>
>>>>>> Standard Squeak uses original menu pin form.
>>>>>> Tweaked appearance of drop lists for Watery 2 as an interim  
>>>>>> measure.
>>>>>> Fixed positioning of drop list pop-up-list to deal with  
>>>>>> transforms
>>>>>> (no
>>>>>> rotation though ;-) ) (thanks Alain)
>>>>>>
>>>>>> Removed "revert" option in patch browser for MC 1.0  
>>>>>> compatability.
>>>>>> Handle missing remote definition when selecting next conflict.
>>>>>>
>>>>>> Stef
>>>>>>
>>>>>> _______________________________________________
>>>>>> Pharo-project mailing list
>>>>>> [hidden email]
>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best regards,
>>>>> Igor Stasenko AKA sig.
>>>>>
>>>>> _______________________________________________
>>>>> Pharo-project mailing list
>>>>> [hidden email]
>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- 
>>>>> project
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> Sadly BitBlt and/or Balloon don't support much so we're stuck with
> GradientFills and rectangles for shapes (where the double-dispatched
> "puting
> the behaviour in the fill style" is concerned, unless the low-level
> shape
> drawing types are all dispatched)...
>
> As for the original question, BoundedGradientFillStyle simply allows
> for an
> extent so that, as part of a composite, it can be limited to only
> part of
> the drawing area. This makes it possible to make composites that have
> different corner images (for example) along with gradients for the
> "stretchy
> bits" in between...
>
> In respect of the isXXX methods, these could be refactored properly
> such
> that the morph informs its fillStyle of bounds changes. For simple
> colours
> this would be effecitvely a no-op, gardients would adjust their
> origin etc.
>
> Regards, Gary
>
> ----- Original Message -----
> From: "Igor Stasenko" <[hidden email]>
> To: <[hidden email]>
> Sent: Saturday, March 14, 2009 9:13 AM
> Subject: Re: [Pharo-project] [ANN] 10252
>
>
>> 2009/3/14 Igor Stasenko <[hidden email]>:
>>> 2009/3/14 Stéphane Ducasse <[hidden email]>:
>>>> I will let gary reply and rollback if necessary. or even better
>>>> integrate next fixes :)
>>>> I thought it was ready for integration.
>>>>
>>> I didn't said its not ready..
>>> I just wanted to point out, that it is half-done, in the way how i
>>> see
>>> it should be done.
>>> It works, of course, but not so elegant as it should be :)
>>>
>>>> stef
>>>> On Mar 14, 2009, at 2:15 AM, Igor Stasenko wrote:
>>>>
>>>>> 2009/3/13 Stéphane Ducasse <[hidden email]>:
>>>>>> Added BoundedGradientFillStyle.
>>>>>
>>>>> can to elaborate , what is it? :)
>>>>>
>>>>> We duscussed the fill styles with Gary a while ago, and the
>>>>> result of
>>>>> a discussion is to make fill styles to know what they need to do
>>>>> to
>>>>> fill the given shape i.e. fill style could be seen as a function:
>>>>> f(shape, canvas)
>>>>>
>>
>> going further with that, all drawings (not only fills) on canvas
>> could
>> be represented by such function
>> f(shape, canvas)
>> but it would require a deep refactorings in bitblt/morphic engine to
>> do such unification.
>>
>> With such approach, it would be easy to introduce a new fill styles,
>> such as bevel/emboss, blur , etc.
>> While old fillstyles implementation is quite limited, because
>> fillstyle used as a dumb state holder and drawing engine performs
>> different tests (isXXXX) to do the right thing.
>>
>>>>> and, to use a fill style, in general form, you simply should use:
>>>>> myfillStyle fill: someShape on: canvas.
>>>>>
>>>>> This concept were introduced into Polymorph, and as first proof
>>>>> of it,
>>>>> Gary implemented a composite fill styles.
>>>>> But it's far from complete. In ideal, i'd like to get rid of many
>>>>> 'isXXXFill', like #isGradientFill and others and remove any code
>>>>> which
>>>>> relying on fill style properties - instead it should always
>>>>> delegate
>>>>> the responsibility from filling a shape to a fill style object.
>>>>>
>>>>> This approach , also opens a new questions:
>>>>> - how do we treat a morph. Should morph define own shape? Or
>>>>> shape is
>>>>> something that should be determined procedurally, and morph could
>>>>> contain/use as many shapes as it wants to for representing
>>>>> itself on
>>>>> canvas?
>>>>> I am far from thinking that morph's shape is rectangular (but
>>>>> there
>>>>> are many aspects in morphic, assuming it is rectangular - such as
>>>>> #fullBounds or #bounds), as well as i don't think that making
>>>>> morph
>>>>> === shape is a good choice.
>>>>>
>>>>>> Standard Squeak uses original menu pin form.
>>>>>> Tweaked appearance of drop lists for Watery 2 as an interim
>>>>>> measure.
>>>>>> Fixed positioning of drop list pop-up-list to deal with
>>>>>> transforms
>>>>>> (no
>>>>>> rotation though ;-) ) (thanks Alain)
>>>>>>
>>>>>> Removed "revert" option in patch browser for MC 1.0
>>>>>> compatability.
>>>>>> Handle missing remote definition when selecting next conflict.
>>>>>>
>>>>>> Stef
>>>>>>
>>>>>> _______________________________________________
>>>>>> Pharo-project mailing list
>>>>>> [hidden email]
>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best regards,
>>>>> Igor Stasenko AKA sig.
>>>>>
>>>>> _______________________________________________
>>>>> Pharo-project mailing list
>>>>> [hidden email]
>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-
>>>>> project
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]] En
> nombre de Stephane Ducasse
> Enviado el: Friday, March 13, 2009 18:27
> Para: Pharo Development
> Asunto: [Pharo-project] [ANN] 10252
>
> Added BoundedGradientFillStyle.
> Standard Squeak uses original menu pin form.
> Tweaked appearance of drop lists for Watery 2 as an interim measure.
> Fixed positioning of drop list pop-up-list to deal with
> transforms (no  
> rotation though ;-) ) (thanks Alain)
>
> Removed "revert" option in patch browser for MC 1.0 compatability.
> Handle missing remote definition when selecting next conflict.
>
> Stef
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project