|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
|
|
Host windowsGary,
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@... Tel: (352) 846-1285 FAX: (352) 392-7029 _______________________________________________ UI mailing list UI@... http://lists.squeakfoundation.org/mailman/listinfo/ui |
|
|
A small change... for a startWell, 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@... http://lists.squeakfoundation.org/mailman/listinfo/ui |
|
|
RE: Host windowsWill 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@... > [mailto:ui-bounces@...]On Behalf Of Bill Schwab > Sent: 01 March 2008 4:16 PM > To: ui@... > 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@... > Tel: (352) 846-1285 > FAX: (352) 392-7029 > > _______________________________________________ > UI mailing list > UI@... > http://lists.squeakfoundation.org/mailman/listinfo/ui _______________________________________________ UI mailing list UI@... http://lists.squeakfoundation.org/mailman/listinfo/ui |
|
|
Re: A small change... for a startGary,
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@... > http://lists.squeakfoundation.org/mailman/listinfo/ui _______________________________________________ UI mailing list UI@... http://lists.squeakfoundation.org/mailman/listinfo/ui |
|
|
Re: A small change... for a startOn 01/03/2008, Travis Kay <tlk@...> 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@... http://lists.squeakfoundation.org/mailman/listinfo/ui |
|
|
RE: A small change... for a startWill have an experiment with composite fill styles over this Easter break.
> -----Original Message----- > From: ui-bounces@... > [mailto:ui-bounces@...]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@...> 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@... > http://lists.squeakfoundation.org/mailman/listinfo/ui > _______________________________________________ UI mailing list UI@... http://lists.squeakfoundation.org/mailman/listinfo/ui |
|
|
Re: A small change... for a startOn 21/03/2008, Gary Chambers <gazzaguru2@...> 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 UI@... http://lists.squeakfoundation.org/mailman/listinfo/ui |
|
|
Re: A small change... for a startMe too! Thanks =)
On Fri, 2008-03-21 at 02:16 +0200, Igor Stasenko wrote: > On 21/03/2008, Gary Chambers <gazzaguru2@...> wrote: > > Will have an experiment with composite fill styles over this Easter break. > > > > > Good news! Eagerly awaiting for results :) > > _______________________________________________ UI mailing list UI@... http://lists.squeakfoundation.org/mailman/listinfo/ui |
|
|
RE: A small change... for a startPinesoft-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@... http://lists.squeakfoundation.org/mailman/listinfo/ui |
|
|
RE: A small change... for a startP.S. Just rectangular fills as a proof of concept for the moment.
> -----Original Message----- > From: ui-bounces@... > [mailto:ui-bounces@...]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@... > http://lists.squeakfoundation.org/mailman/listinfo/ui > _______________________________________________ UI mailing list UI@... http://lists.squeakfoundation.org/mailman/listinfo/ui |
|
|
RE: A small change... for a startExcellent 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@... > > [mailto:ui-bounces@...]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@... > > http://lists.squeakfoundation.org/mailman/listinfo/ui > > > > _______________________________________________ > UI mailing list > UI@... > http://lists.squeakfoundation.org/mailman/listinfo/ui _______________________________________________ UI mailing list UI@... http://lists.squeakfoundation.org/mailman/listinfo/ui |
|
|
|
|
|
Re: A small change... for a startOn 21/03/2008, Gary Chambers <gazzaguru2@...> wrote:
> P.S. Just rectangular fills as a proof of concept for the moment. > > > > -----Original Message----- > > From: ui-bounces@... > > > [mailto:ui-bounces@...]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 UI@... http://lists.squeakfoundation.org/mailman/listinfo/ui |
|
|
Re: A small change... for a startAnother, 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@...> wrote: > On 21/03/2008, Gary Chambers <gazzaguru2@...> wrote: > > > P.S. Just rectangular fills as a proof of concept for the moment. > > > > > > > -----Original Message----- > > > From: ui-bounces@... > > > > > [mailto:ui-bounces@...]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 UI@... http://lists.squeakfoundation.org/mailman/listinfo/ui |
|
|
|
|
|
Re: A small change... for a startOn 22/03/2008, Gary Chambers <gazzaguru2@...> 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 UI@... http://lists.squeakfoundation.org/mailman/listinfo/ui |
|
|
|
|
|