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
