saving window top/left in the image, and what does it mean?

For reasons lost in time, although one of the readers might now, the  
vm stores the window width/height in the image file, but not the top/
left.

Now Eliot Miranda asked me about launching Squeak on his mac and  
having it show up as full screen on the secondary display. Which of
course does not happen since it opens on the main display and goes to  
full screen there.  To do this I would need to know that I have to place
the window on the secondary display, or elsewhere in the coordinate  
system which would be the secondary display, then go to full screen.


I'd like to propose that we grab another 4 bytes (8 bytes?) out of  
the header and store the top/left in mmm macintosh quickdraw  
coordinate systems values.
Then on main window open a VM would need to see if the window created  
based on the top/left be visible, if so to open it at those  
coordinates, otherwise
fall back to the historical code.   I realize of course this might  
not work for Xwindows or Windows (no clue) but even just having the  
ability to position a
squeak window at startup at a given location is more useful than our  
fall back position of 44 & 8.

Perhaps even suggesting a number (2) meaning use the secondary screen  
or something, mm and top/left being 0/0 of top/left of 2nd screen.

Thoughts?  Well one part is do we need this?
The second is how to implement in a manner that all VMs would do the  
right thing based on some magic numbers.

--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===

Oh sure make me work all weekend on Sophie, and I forget *all* about  
Ffenstri, has to be your fault Tim. I mean that assumes there is  
*any* interest in
Ffenstri you know, well I did repackage for 3.10, likely works under  
3.9 too.


mmm one thing we don't have is access to window (1) which by default  
is the window opened by the vm...
Lets see

hwp := HostWindowProxy new.
hwp windowHandle: 1.  "create this accessor"
hwp on: Display.
hwp windowPosition: 100@100

I doubt closing window (1) would be a good thing to do, likely the  
mac carbon VM will freak, must fix that...

ya, open squeak, use windowPosition: to put where you want window.

On Jan 23, 2007, at 2:39 PM, tim Rowledge wrote:

--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===

Dear John,

first of all I will say that I know very little about the vm, or how
squeak starts up. I have had a go at refactoring AutoStart and I have
had some ideas in that area.

I am assuming that the vm is responsible for initializing a display for
squeak before squeak has got up and running to use it. Is this the case?
Does it have to be the case?

I am interested in eventually producing a minimum image whose aim is to
handle the following command line (or similar).

#squeak min.image Script e="2+2"

I am wondering if the startup process for my minimum image is going to
always be slowed down by the initialization of the display that I dont
need.

Does -headless skip the initialization of the display and send drawing
commands into the void? I dont know how headless works. Can the image
control whether it is headless or not?

I know that I have a lot of questions, I hope that you can see why I am
asking them.

what do you think?

best regards

Keith

       
       
               
___________________________________________________________
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
http://uk.docs.yahoo.com/nowyoucan.html

On 23-Jan-07, at 7:52 PM, Keith Hodges wrote:


>
> I am assuming that the vm is responsible for initializing a display  
> for squeak before squeak has got up and running to use it. Is this  
> the case? Does it have to be the case?
It was the case generally (win/mac/unix but not RISC OS ) until we  
did the Ffenestri work at which point any vm that is Ffenestri-aware  
should be able to not open any window until and unless some code  
actually pushes pixels to a window pixmap.

>
> I am interested in eventually producing a minimum image whose aim  
> is to handle the following command line (or similar).
>
> #squeak min.image Script e="2+2"

Don't forget to take a look at Spoon (http://www.netjam.org/spoon/)  
in that case. Craig has done some amazing things to make miniscule  
images possible.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Ought to have a warning label on his forehead.

Well the headless flag means say for the unix vm it stubs in the  
sqUnixDisplayNull logic for things to do with the display.
like asking for it's size, drawing to it does nothing, etc.

Same basically for the mac carbon vm, if headless we don't create a  
main window, calls for window size return dummy value, drawing does  
nothing.
I'll note that basically drawing means copying bits from a squeak  
form to the display device for the platform,  so headless, why we  
just return.

The point that Tim makes is that currently there is an assumption  
that headful VMs make an window for display ID 1, automatically,  
versus changing the image so that Ffenestri would decide oh, I should  
create a window and anchor Display on it.

  10  years back  the mac VM open the window, ground along, resized  
the window based on choices in the image, then displayed the bits.    
Currently the mac carbon vm makes a hidden window of the size  
indicated by the image, then only shows the window when the first  
draw request comes  in.  This of course has led to some issues  
because if an image is so broken it cannot schedule a draw event you  
will not get a window, which means the cmd-key-period combination  
won't work because we need a window in order to accept the  
keystroke.  On the other hand the window doesn't come up white  
because squeak hasn't gotten around to drawing in. Mind this  
optimization is less apparent because machines are very fast now, but  
oh 8 years back it was a different story.

One thing of course to chase in all of this is how long does it take  
to get the image up in a sane state. The message tracing VM I build  
allows one to trace all message sends which might surprise people.    
I'lll note that allInstances is really slow, and asking for Foo  
someObject then Foo nextObject is really fast. mmm Ah trace yes on my  
idisk is a trace of image startup, in the experimental folder on my  
idisk, via http://www.smalltalkconsulting.com/squeak.html

MinimalImage-7061b.messageTraceFile.txt.zip

An interesting exercise for someone would be to turn it into  
something the MessageTally logic could work with.

Um of course Craig's work disposes of all those messages because he  
disposes of all the methods except the ones you actually need to do  
say your "2+2"

On Jan 23, 2007, at 7:52 PM, Keith Hodges wrote:

--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===