Smalltalk › Squeak › Squeak VM

[OpenSmalltalk/opensmalltalk-vm] Fallback window size Mac windows is too small (#288)

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

10 messages Options

David T Lewis

[OpenSmalltalk/opensmalltalk-vm] Fallback window size Mac windows is too small (#288)

When the image is saved in headless mode, the window size is set to extension 10@10. This value is too small.

see opensmalltalk-vm/platforms/Mac OS/vm/Developer/sqMacMinimal.c, line 531

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

David T Lewis

Re: [OpenSmalltalk/opensmalltalk-vm] Fallback window size on Mac is too small (#288)

Hey @pavel-krivanek, if you reference the fogbugz site, please at least include the gist of its discussion here. Fogbugz is a closed site and not everybody has an account there.,=

Also, can you tell why 10 @ 10 is too small?
Why does a headless mode bother with the extent in the first place?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

David T Lewis

Re: [OpenSmalltalk/opensmalltalk-vm] Fallback window size on Mac is too small (#288)

In reply to this post by David T Lewis

The issue was described with this code

curl get.pharo.org/60+vm | bash
./pharo Pharo.image save 1.image
./pharo-ui 1.image

When you did it, the Pharo started but no UI was shown. Then we realized that the UI actually started and the window was opened but it was so small that it was hard to notice.
So, when you start the image in headless mode, the VM during saving sets the real window size and since the headless VM has no window, it is set to fallback values (10@10).
Then when the image is started in standard mode with the display, it extremely small.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Tobias Pape

Re: [OpenSmalltalk/opensmalltalk-vm] Fallback window size on Mac is too small (#288)

hi Pavel.

this is not a bug in the vm. it's the images responsibility to set the correct size before saving.
--
Sent from a mobile device

David T Lewis

Re: [OpenSmalltalk/opensmalltalk-vm] Fallback window size on Mac is too small (#288)

In reply to this post by David T Lewis

I'm pretty sure it is a VM problem. For example on Linux it works as expected (which kind of supports that it is VM related). Mac does not take the display size from the Display but from the window, see the related method:

int ioScreenSize(void) {
	/* return the screen size as two positive 16-bit integers packed into a 32-bit integer */
	int w = 10, h = 10;

	if (stWindow != nil) {
		w = stWindow->portRect.right - stWindow->portRect.left;
		h = stWindow->portRect.bottom - stWindow->portRect.top;
	}
	return (w << 16) | (h & 0xFFFF);  /* w is high 16 bits; h is low 16 bits */
}

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

David T Lewis

Re: [OpenSmalltalk/opensmalltalk-vm] Fallback window size on Mac is too small (#288)

In reply to this post by David T Lewis

(note that platforms/Mac OS/vm/Developer/sqMacMinimal.c is no longer used, it is from the deprecated Carbon Mac VM)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

David T Lewis

Re: [OpenSmalltalk/opensmalltalk-vm] Fallback window size on Mac is too small (#288)

In reply to this post by David T Lewis

Ok, here's the roundup:

Mac: seems to has ever used 10@10 as fallback, apparently since the 1990s (fallback still )
But sometimes returns 16@16 when headless is detected
Windows:
- Tries window's size, if window is there
- Tries saved size (which comes from image)
  However, when setting the window size, it
- Avoids doing that in headless mode
- Tries saved size (which comes from vm),
- Uses default of 640@480 (aka VGA)
- but makes sure that it's at least 64@64
Which means that one call to SetWindowSize makes everything even more inconsistent
Unix: First note: reading the Screen size actually can change the physical screen size
- Starts from the images saved size (which comes from image)
- In headless, gives that saved size or, if that is not available, just 64@64
- Only then, after possible resizing of the physical window, the actual size is determined

Nothing of this is consistent. The most common thing is to return the saved size or 64@64.

The only thing to fix that here is to actually make the Cocoa VM query the image for its saved size, yes.
But save for that, I would avoid hardcoding like #289 .

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

David T Lewis

Re: [OpenSmalltalk/opensmalltalk-vm] Fallback window size on Mac is too small (#288)

In reply to this post by David T Lewis

Thank you for the analysis. I will close that PR

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

timrowledge

Re: [OpenSmalltalk/opensmalltalk-vm] Fallback window size on Mac is too small (#288)

In reply to this post by David T Lewis

I've argued for a long time - probably decades by now - that the VM should not be opening a window until and unless the image requests one. On RISC OS no window is even created, let alone opened until the first call to display the screen bitmap. It makes headless a trivial choice of the image setting.

I know that at one time, Windows had to have a window of sorts in order for moust(etc) events to be dealt with and other important stuff, but surely that stage is long gone.

Remembering the window size and default opening the window is an artefact of ancient code that simply has no sensible place in today's Smalltalk.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Oxymorons: Good grief

David T Lewis

Re: [OpenSmalltalk/opensmalltalk-vm] Fallback window size on Mac is too small (#288)

In reply to this post by David T Lewis

Closed #288 via #291.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.