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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
Free forum by Nabble | Edit this page |