Host windows

> -----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

> 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

> -----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
>

> -----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
>

> 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

> 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!
>  >

> 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.
>

> 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!
>  >