The current experiment works by double dispatch to "simple" methods that were previously the main entry point on Canvas, for compatibility. So provides the flexibility of FillStyles to utilise the existing capabilities of various canvasses.
Ideally the whole thing could be restructured back to Canvas to efficiently deal with compositing. For the moment this achieves the overall aim without excessive redesign.
----- Original message ----- From: Igor Stasenko siguctua@gmail.com To: Squeak's User Interface ui@lists.squeakfoundation.org Sent: Fri, 21 Mar 2008, 23:13:43 GMT Subject: Re: [UI] A small change... for a start On 21/03/2008, Gary Chambers gazzaguru2@btinternet.com wrote:
P.S. Just rectangular fills as a proof of concept for the moment.
-----Original Message----- From: ui-bounces@lists.squeakfoundation.org
[mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Gary Chambers Sent: 21 March 2008 5:59 PM To: Squeak's User Interface
Subject: RE: [UI] A small change... for a start
Pinesoft-Widgets-gvc.302 on SqueakMap. Nebraska not included in changes (may do a separate package for that if there is interest).
Added CompositeFillStyle. Canvas double-dispatches to the fillstyle/color/infiniteForm. Should allow more complex fills through subclassing(like pieced together from forms for a button, top-left image, top image etc.).
Have fun!
It looks double-dispatch needed from a BaloonEngine, not from Canvas. A fillStyle needs method #registerFillWith: engine.
So, it will dispatch back to BalloonEngine with messages like:
^ engine registerSolidFill: self. "For single color fill"
^ engine registerGradientFill: self "For gradient fill"
^ engine registerBitmapFill: self "For bitmap fill"
And BaloonEngine>>registerFill: aFill should look like: ^ aFill registerFillWith: self.
Otherwise we need to extend canvas protocol with methods:
#fillRectangle:color: #fillRectangle:gradient: #fillRectangle:bitmap:
I don't like that there is need in additional checking for fill type later, after canvas receives #fillRectangle:basicFillStyle: i think it would be better to be precise after dispatch, what basic fill type should be used.
Gary
On 22/03/2008, Gary Chambers gazzaguru2@btinternet.com wrote:
The current experiment works by double dispatch to "simple" methods that were previously the main entry point on Canvas, for compatibility. So provides the flexibility of FillStyles to utilise the existing capabilities of various canvasses.
Ideally the whole thing could be restructured back to Canvas to efficiently deal with compositing. For the moment this achieves the overall aim without excessive redesign.
I think that your work with FillStyles highlighted some problems in Morphic, which cannot be handled as extension. For instance, a reason why morph asks if fillstyle isOrientedFill is to update a oriented fill origin point, when morph changes it's position.
Which, in own turn, shows that it was a bad design choice to specify origin of gradient in screen-space coordinates, instead of coordinates relative to morph.
But now, we can easily deal with that, because we dispatch to fill style. So, fill style can choose how it can fill, and using what coordinates - relative to morph or absolute. And finally, we can get rid isXXXFill protocol.
On Mar 23, 2008, at 4:17 , Igor Stasenko wrote:
Which, in own turn, shows that it was a bad design choice to specify origin of gradient in screen-space coordinates, instead of coordinates relative to morph.
Well, since coordinates in Morphic are absolute anyway, it was an obvious choice. It's wrong, agreed, but I doubt it's feasible to change Morphic to relative coordinates without a lot of breakage.
- Bert -