[ANN] 10252

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

[ANN] 10252

Stéphane Ducasse
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
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] 10252

Igor Stasenko
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
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] 10252

Stéphane Ducasse
I will let gary reply and rollback if necessary. or even better  
integrate next fixes :)
I thought it was ready for integration.

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
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] 10252

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] 10252

Igor Stasenko
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
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] 10252

Gary Chambers-4
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
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] 10252

Stéphane Ducasse
a question:
would it help to have rome canvas?
because I would really like to curve it out of sophie for 1.1

stef
On Mar 14, 2009, at 2:59 PM, Gary Chambers wrote:

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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] 10252

Gary Chambers-4
A lot more could be done with Rome, though only then availbale for platforms
with Cario...

Regards, Gary

----- Original Message -----
From: "Stéphane Ducasse" <[hidden email]>
To: <[hidden email]>
Sent: Saturday, March 14, 2009 3:22 PM
Subject: Re: [Pharo-project] [ANN] 10252


a question:
would it help to have rome canvas?
because I would really like to curve it out of sophie for 1.1

stef
On Mar 14, 2009, at 2:59 PM, Gary Chambers wrote:

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


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] 10252

Michael Rueger-6
Gary Chambers wrote:
> A lot more could be done with Rome, though only then availbale for platforms
> with Cario...

That is not entirely true.
Rome has also a Balloon backend, though ti hasn't been updated in a while.
It should also be possible to build a BitBlt back end with fallbacks for
unsupported features like certain gradients.

Michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] 10252

Michael Rueger-6
Michael Rueger wrote:
> Gary Chambers wrote:
>> A lot more could be done with Rome, though only then availbale for platforms
>> with Cario...
>
> That is not entirely true.
> Rome has also a Balloon backend, though ti hasn't been updated in a while.
> It should also be possible to build a BitBlt back end with fallbacks for
> unsupported features like certain gradients.

Hmm, thinking about it a second more ;-)
BitBlt would only make sense for relatively simple graphics as otherwise
you would need Balloon's features for drawing curves etc.

Michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] 10252

Sebastian Sastre-2
In reply to this post by Stéphane Ducasse
noob question: downloadable from?
or is just updating a 243?
sebastian

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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] 10252

Damien Cassou
On Tue, Mar 17, 2009 at 4:35 AM, Sebastian Sastre <[hidden email]> wrote:
> noob question: downloadable from?
> or is just updating a 243?

All downloadable versions are in:
https://gforge.inria.fr/frs/?group_id=1299

If you can't find in you have to update.

--
Damien Cassou
http://damiencassou.seasidehosting.st

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project