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: bschwab@anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029
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.
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 UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
On 01/03/2008, Travis Kay tlk@nb.sympatico.ca 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.
Will have an experiment with composite fill styles over this Easter break.
-----Original Message----- From: ui-bounces@lists.squeakfoundation.org [mailto:ui-bounces@lists.squeakfoundation.org]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 tlk@nb.sympatico.ca 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 UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
On 21/03/2008, Gary Chambers gazzaguru2@btinternet.com wrote:
Will have an experiment with composite fill styles over this Easter break.
Good news! Eagerly awaiting for results :)
Me too! Thanks =)
On Fri, 2008-03-21 at 02:16 +0200, Igor Stasenko wrote:
On 21/03/2008, Gary Chambers gazzaguru2@btinternet.com wrote:
Will have an experiment with composite fill styles over this Easter break.
Good news! Eagerly awaiting for results :)
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
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!
Gary
UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
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: 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!
Gary
UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
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
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 siguctua@gmail.com wrote:
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
-- Best regards, Igor Stasenko AKA sig.
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: ui-bounces@lists.squeakfoundation.org [mailto:ui-bounces@lists.squeakfoundation.org]On Behalf Of Bill Schwab Sent: 01 March 2008 4:16 PM To: ui@lists.squeakfoundation.org 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: bschwab@anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029
UI mailing list UI@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/ui
-
Bill Schwab -
Gary Chambers -
Igor Stasenko -
Travis Kay