2009/3/14 Igor Stasenko <siguctua@gmail.com>:
2009/3/14 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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 <stephane.ducasse@inria.fr>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.