A lot more could be done with Rome, though only then availbale for platforms with Cario...
Regards, Gary ----- Original Message ----- From: "Stéphane Ducasse" <[email protected]> To: <[email protected]> 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" <[email protected]> > To: <[email protected]> > Sent: Saturday, March 14, 2009 9:13 AM > Subject: Re: [Pharo-project] [ANN] 10252 > > >> 2009/3/14 Igor Stasenko <[email protected]>: >>> 2009/3/14 Stéphane Ducasse <[email protected]>: >>>> 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 <[email protected]>: >>>>>> 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 >>>>>> [email protected] >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [email protected] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [email protected] >>>> 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 >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
