Host windows

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Host windows

Schwab,Wilhelm K
Gary,

Having just stumbled on Squeak's SSL stack, I have another piece of my
MS escape plan, at least to the point of being able to do some serious
porting and stress testing.  At the mission-critical level, there is one
fairly intense fat client (that is where your work is most relevant to
my plans), and various server apps.  The latter have run as desktop apps
under Dolphin, but that is becoming a problem as we move (over my
unilaterally[*] bruised body) to virtual machines in racks.  My plan is
to build SSL into Kom and end up with "out of the box" secure
Seaside-based configuration.  Settings can be persisted by simply saving
the image.

Now the point (about time, I realize).  The server apps will probably
spend most of their lives in a headless configuration, but I will no
doubt at times run them graphically to debug something.  I have said
this before, but I am becoming ever more convinced: using multiple host
windows would be great, but we should also have the option of using
system windows inside of one main Squeak window.  I *think* the latter
will be most useful for the debugging scenario above, but we should try
not to lose the ability as we add the attractive idea of having browsers
and debuggers floating around on an OS desktop.

Thanks for your contributions to Squeak!!

Bill


[*] It is not all bad.  I fear the VMs are in use out of mainstreamism,
and they will almost certainly go from quick to overloaded with time.
Having them locked up with dedicated staff to make backups, etc. is a
good thing, both because it needs to be formalized, and because *I*
don't have to do it ;)




Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

A small change... for a start

Gary Chambers-4
Well, not that small.

After a lengthy discussion with Sig (Igor) last night we came to the
conclusion that it would be nice to improve the behaviour of
colours/fillstyles passed to canvases for drawing.

At present, the canvas code directly checks the type of fillstyle and does
things accordingly. It would, IMHO, be better if the canvas
double-dispatched to the fillstyle to achieve its ends.

This would allow, for instance, a CompositeFillStyle class to be
implemented, facilitating fills of the kind shown in the attachments (from
Sig).

All without having to rework Morphic's handling of its fillstyles (short of
actually assigning a new kind of fillstyle to a particular Morph).

Even the more esoteric example from Sig (star_fills) would be possible.
Of course, the suggested composite fill would be cool enough!

Comments around this would be welcome before I proceed...

Regards, Gary.

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui

fills.png (16K) Download Attachment
star_fills.png (42K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Host windows

Gary Chambers-4
In reply to this post by Schwab,Wilhelm K
Will wait to see what Adrien comes up with. As far as I envision things,
platform widgets/windows would be cross-useable with each other (think
HostWindow/SystemWindow add: MyVisualThing(s)).

Gary

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On Behalf Of Bill Schwab
> Sent: 01 March 2008 4:16 PM
> To: [hidden email]
> Subject: [UI] Host windows
>
>
> Gary,
>
> Having just stumbled on Squeak's SSL stack, I have another piece of my
> MS escape plan, at least to the point of being able to do some serious
> porting and stress testing.  At the mission-critical level, there is one
> fairly intense fat client (that is where your work is most relevant to
> my plans), and various server apps.  The latter have run as desktop apps
> under Dolphin, but that is becoming a problem as we move (over my
> unilaterally[*] bruised body) to virtual machines in racks.  My plan is
> to build SSL into Kom and end up with "out of the box" secure
> Seaside-based configuration.  Settings can be persisted by simply saving
> the image.
>
> Now the point (about time, I realize).  The server apps will probably
> spend most of their lives in a headless configuration, but I will no
> doubt at times run them graphically to debug something.  I have said
> this before, but I am becoming ever more convinced: using multiple host
> windows would be great, but we should also have the option of using
> system windows inside of one main Squeak window.  I *think* the latter
> will be most useful for the debugging scenario above, but we should try
> not to lose the ability as we add the attractive idea of having browsers
> and debuggers floating around on an OS desktop.
>
> Thanks for your contributions to Squeak!!
>
> Bill
>
>
> [*] It is not all bad.  I fear the VMs are in use out of mainstreamism,
> and they will almost certainly go from quick to overloaded with time.
> Having them locked up with dedicated staff to make backups, etc. is a
> good thing, both because it needs to be formalized, and because *I*
> don't have to do it ;)
>
>
>
>
> Wilhelm K. Schwab, Ph.D.
> University of Florida
> Department of Anesthesiology
> PO Box 100254
> Gainesville, FL 32610-0254
>
> Email: [hidden email]
> Tel: (352) 846-1285
> FAX: (352) 392-7029
>
> _______________________________________________
> UI mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/ui

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

Re: A small change... for a start

Travis Kay
In reply to this post by Gary Chambers-4
Gary,

This sounds like a good idea to me; improves the overall design and adds
some very nice flexibility.

Travis

On Sat, 2008-03-01 at 18:42 +0000, Gary Chambers wrote:

> Well, not that small.
>
> After a lengthy discussion with Sig (Igor) last night we came to the
> conclusion that it would be nice to improve the behaviour of
> colours/fillstyles passed to canvases for drawing.
>
> At present, the canvas code directly checks the type of fillstyle and does
> things accordingly. It would, IMHO, be better if the canvas
> double-dispatched to the fillstyle to achieve its ends.
>
> This would allow, for instance, a CompositeFillStyle class to be
> implemented, facilitating fills of the kind shown in the attachments (from
> Sig).
>
> All without having to rework Morphic's handling of its fillstyles (short of
> actually assigning a new kind of fillstyle to a particular Morph).
>
> Even the more esoteric example from Sig (star_fills) would be possible.
> Of course, the suggested composite fill would be cool enough!
>
> Comments around this would be welcome before I proceed...
>
> Regards, Gary.
> _______________________________________________
> UI mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/ui

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

Re: A small change... for a start

Igor Stasenko
On 01/03/2008, Travis Kay <[hidden email]> wrote:
> Gary,
>
>  This sounds like a good idea to me; improves the overall design and adds
>  some very nice flexibility.
>

Indeed!
Interesting, that if we step back and look at things at more abstract
approach, then all operations like fills and borders is nothing more
than a function:
f (shape)
where shape is polygonal (can be hollow or not).

>From engine's POV things could be unified - there is no need to
distinct between fills and drawing borders.
The difference lies in kind of operation and its parameters, but
everything is always based on shape.

Baloon engine are quite limited to solid fills and 2 kinds of gradient fills.
There can be much more techniques based on different pixel operations
by having polygonal shape:
- embossing
- outer/inner glows and shadows
and many more.

But even having current primitive capabilities we can achieve much
more if use composite fill styles:
f(shape) = a(shape)*b(shape)*c(shape)...

where a,b,c is basic kinds of operations, currently available to us.

--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

RE: A small change... for a start

Gary Chambers-4
Will have an experiment with composite fill styles over this Easter break.

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On Behalf Of Igor Stasenko
> Sent: 01 March 2008 11:00 PM
> To: Squeak's User Interface
> Subject: Re: [UI] A small change... for a start
>
>
> On 01/03/2008, Travis Kay <[hidden email]> wrote:
> > Gary,
> >
> >  This sounds like a good idea to me; improves the overall
> design and adds
> >  some very nice flexibility.
> >
>
> Indeed!
> Interesting, that if we step back and look at things at more abstract
> approach, then all operations like fills and borders is nothing more
> than a function:
> f (shape)
> where shape is polygonal (can be hollow or not).
>
> >From engine's POV things could be unified - there is no need to
> distinct between fills and drawing borders.
> The difference lies in kind of operation and its parameters, but
> everything is always based on shape.
>
> Baloon engine are quite limited to solid fills and 2 kinds of
> gradient fills.
> There can be much more techniques based on different pixel operations
> by having polygonal shape:
> - embossing
> - outer/inner glows and shadows
> and many more.
>
> But even having current primitive capabilities we can achieve much
> more if use composite fill styles:
> f(shape) = a(shape)*b(shape)*c(shape)...
>
> where a,b,c is basic kinds of operations, currently available to us.
>
> --
> Best regards,
> Igor Stasenko AKA sig.
> _______________________________________________
> UI mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/ui
>

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

Re: A small change... for a start

Igor Stasenko
On 21/03/2008, Gary Chambers <[hidden email]> wrote:
> Will have an experiment with composite fill styles over this Easter break.
>
>
Good news! Eagerly awaiting for results :)


--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

Re: A small change... for a start

Travis Kay
Me too! Thanks =)

On Fri, 2008-03-21 at 02:16 +0200, Igor Stasenko wrote:
> On 21/03/2008, Gary Chambers <[hidden email]> wrote:
> > Will have an experiment with composite fill styles over this Easter break.
> >
> >
> Good news! Eagerly awaiting for results :)
>
>

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

RE: A small change... for a start

Gary Chambers-4
In reply to this post by Gary Chambers-4
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!

Gary

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

RE: A small change... for a start

Gary Chambers-4
P.S. Just rectangular fills as a proof of concept for the moment.

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]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!
>
> Gary
>
> _______________________________________________
> UI mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/ui
>

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

RE: A small change... for a start

Travis Kay
Excellent just the same, thank you Gary.

Travis

On Fri, 2008-03-21 at 18:00 +0000, Gary Chambers wrote:

> P.S. Just rectangular fills as a proof of concept for the moment.
>
> > -----Original Message-----
> > From: [hidden email]
> > [mailto:[hidden email]]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!
> >
> > Gary
> >
> > _______________________________________________
> > UI mailing list
> > [hidden email]
> > http://lists.squeakfoundation.org/mailman/listinfo/ui
> >
>
> _______________________________________________
> UI mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/ui

_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

Re: A small change... for a start

Gary Chambers-4
In reply to this post by Gary Chambers-4
Might now embark on a new theme as a showcase of the facility. STNG (Squeak The Next Generation). Fast machines only, maybe! :-)

Gary
_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

Re: A small change... for a start

Igor Stasenko
In reply to this post by Gary Chambers-4
On 21/03/2008, Gary Chambers <[hidden email]> wrote:

> P.S. Just rectangular fills as a proof of concept for the moment.
>
>
>  > -----Original Message-----
>  > From: [hidden email]
>
> > [mailto:[hidden email]]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
>  >
--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

Re: A small change... for a start

Igor Stasenko
Another, maybe more elegant way is to add
a pattern like:

canvas withFillStyle: aStyle do:  aBlock.

and inside a block use calls like:
canvas fillRect: aRect.
canvas fillPolygon: aPoly
etc

On 22/03/2008, Igor Stasenko <[hidden email]> wrote:

> On 21/03/2008, Gary Chambers <[hidden email]> wrote:
>
> > P.S. Just rectangular fills as a proof of concept for the moment.
>  >
>  >
>  >  > -----Original Message-----
>  >  > From: [hidden email]
>  >
>  > > [mailto:[hidden email]]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
>
> >  >
>  --
>  Best regards,
>  Igor Stasenko AKA sig.
>


--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

Re: A small change... for a start

Gary Chambers-4
In reply to this post by Gary Chambers-4
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  <[hidden email]>
To: Squeak's User Interface  <[hidden email]>
Sent: Fri, 21 Mar 2008, 23:13:43 GMT
Subject: Re: [UI] A small change... for a start
On 21/03/2008, Gary Chambers <[hidden email]> wrote:

> P.S. Just rectangular fills as a proof of concept for the moment.
>
>
>  > -----Original Message-----
>  > From: [hidden email]
>
> > [mailto:[hidden email]]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
>  >
--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

Re: A small change... for a start

Igor Stasenko
On 22/03/2008, Gary Chambers <[hidden email]> 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.

--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

Re: A small change... for a start

Gary Chambers-4
In reply to this post by Gary Chambers-4
But the fillstyle is only now aware of the canvas, not the morph (was neither before).

Agree with you on relative vs absolute coordinates though.

TC. Gary.


----- Original message -----
From: Igor Stasenko  <[hidden email]>
To: Squeak's User Interface e canv <[hidden email]>
Sent: Sun, 23 Mar 2008, 03:17:39 GMT
Subject: Re: [UI] A small change... for a start
On 22/03/2008, Gary Chambers <[hidden email]> 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.

--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

Re: A small change... for a start

Igor Stasenko
On 23/03/2008, Gary Chambers <[hidden email]> wrote:
> But the fillstyle is only now aware of the canvas, not the morph (was neither before).
>

Yes, it's not and shouldn't be.
As far a morph provides a coordinates of areas to fill, only the
fillstyle can choose how to fill them.
An isXXXFill patterns is really shows that parts of fillstyle behavior
are handled by external entities, which adds complexity and
uncertainty to many places in code.

>  Agree with you on relative vs absolute coordinates though.
>
>  TC. Gary.
>
>


--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

Re: A small change... for a start

Gary Chambers-4
In reply to this post by Gary Chambers-4
Well, to my mind there is no need for fillstyle type testing in a properly refactored Morphic. There is with what we currently have. (Will post again with a more comprehensive outlook on things).

----- Original message -----
From: Igor Stasenko  <[hidden email]>
To: Squeak's User Interface  <[hidden email]>
Sent: Sun, 23 Mar 2008, 03:36:35 GMT
Subject: Re: [UI] A small change... for a start
On 23/03/2008, Gary Chambers <[hidden email]> wrote:
> But the fillstyle is only now aware of the canvas, not the morph (was neither before).
>

Yes, it's not and shouldn't be.
As far a morph provides a coordinates of areas to fill, only the
fillstyle can choose how to fill them.
An isXXXFill patterns is really shows that parts of fillstyle behavior
are handled by external entities, which adds complexity and
uncertainty to many places in code.

>  Agree with you on relative vs absolute coordinates though.
>
>  TC. Gary.
>
>


--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
Reply | Threaded
Open this post in threaded view
|

Re: A small change... for a start

Igor Stasenko
On 23/03/2008, Gary Chambers <[hidden email]> wrote:
> Well, to my mind there is no need for fillstyle type testing in a properly refactored Morphic. There is with what we currently have. (Will post again with a more comprehensive outlook on things).
>

Btw, there are nice work with adding a fill handles to gradient fills
(see FunSqueak image).


--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
UI mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/ui
12