Host windows

View: New views
20 Messages — Rating Filter:   Alert me  
< Prev | 1 - 2 | Next >

Host windows

by Bill Schwab :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

A small change... for a start

by Gary Chambers-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

fills.png (16K) Download Attachment
star_fills.png (42K) Download Attachment

RE: Host windows

by Gary Chambers-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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@...
> [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 start

by Travis Kay :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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@...
> http://lists.squeakfoundation.org/mailman/listinfo/ui

_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

Re: A small change... for a start

by Igor Stasenko :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

RE: A small change... for a start

by Gary Chambers-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

by Igor Stasenko :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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


--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

Re: A small change... for a start

by Travis Kay :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

by Gary Chambers-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

RE: A small change... for a start

by Gary Chambers-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

RE: A small change... for a start

by Travis Kay :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

Parent Message unknown Re: A small change... for a start

by Gary Chambers-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

Re: A small change... for a start

by Igor Stasenko :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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.
_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

Re: A small change... for a start

by Igor Stasenko :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

Parent Message unknown Re: A small change... for a start

by Gary Chambers-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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@...>
To: Squeak's User Interface  <ui@...>
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@...> 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
_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui

Re: A small change... for a start

by Igor Stasenko :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 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

Parent Message unknown Re: A small change... for a start

by Gary Chambers-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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  <siguctua@...>
To: Squeak's User Interface e canv <ui@...>
Sent: Sun, 23 Mar 2008, 03:17:39 GMT
Subject: Re: [UI] A small change... for a start
On 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
_______________________________________________
UI mailing list
UI@...
http://lists.squeakfoundation.org/mailman/listinfo/ui