Lazy Display init (Was: Re: [ENH] Splash screen)

Bert Freudenberg bert at isgnw.CS.Uni-Magdeburg.De
Mon May 22 09:40:35 UTC 2000


On Sun, 21 May 2000, Tim Rowledge wrote:

> In message <20000521112246.A24406 at conch.msen.com>
>           "David T. Lewis" <lewis at mail.msen.com> wrote:
> 
> > On Thu, May 18, 2000 at 09:33:08PM +0200, Bert Freudenberg wrote:
> > > On Thu, 18 May 2000, Tim Rowledge wrote:
> > > 
> > > > One part of this could be done by adopting the changed semantics of
> > > > beDisplay that I use on the Acorn; the window is not created
> > > > until/unless that prim is called.[snip]
> > 
> > Actually, I did this once before, based on Tim's suggestions. I'm attaching
> > a copy of my earlier message.
> That's an interesting way of handling it. I did it all within the Acorn
> specific vm code to avoid any need for persuading people to incorporate
> image changes in such a sensitive area. We should probably revisit the
> idea properly sometime.

Now is the time ;-)

I suggest naming it ioOpenDisplay(displayOop) for consistency with the
other io functions. The default implementation would just return 1.

Then, we could start thinking (again) about multiple OS windows. We would
need some more primitives that take a display id. The id would be returned
by ioOpenDisplay and used in ioForceDisplayUpdateID, ioScreenSizeID,
ioSetCursorID, and ioShowDisplayID. To make input easy to implement there
could be the concept of a "current" display (which corresponds to an
active OS window). Functions ioMousePoint, ioGetButtonState,
ioGetKeystroke, ioPeekKeystroke would answer the values for the current
display. In addition we'd need ioCloseDisplayID and ioActiveDisplay() or
something similar.

On the Squeak side, a world would have a DisplayScreen instance to draw
on. Input should be moved to DisplayScreen, too. Or better yet, make a new
DisplayScreen subclass Terminal which sort of merges InputSensor methods
into DisplayScreen. A PhysicalTerminal would hold the ID. All
PhysicalTerminals need to be known to the VM via a special objects array
to access their display bits for redraw. The "current" world would be the
one which can get input, while the others are output-only and run
doOneCycleInBackground (if needed).

How does this sound?

-- Bert





More information about the Squeak-dev mailing list