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
