[squeak-dev] Finishing 5.2 (was Re: Project for 'after 5.2 release')

Chris Muller asqueaker at gmail.com
Mon Aug 13 18:52:29 UTC 2018

Hi guys,

May we take a step back and refresh our memory from prior release
discussions, the use cases concerning the default window size.
There are hardware considerations and usability considerations.  With
embedded and IoT, small hardware is here to stay.  There are lots of
things that can be done in Squeak which will desire a large or small
screen, one size cannot possibly accommodate everything, but
generally, the most-accomodating *default image window size* would be
one that either accomodates small devices (800x600), or otherwise
full-screen for that device.

The "middle ground" 1024x768 is the one that satisfies virtually no
use cases.  When Squeak would be opened 1024 wide on a small device,
an image window that overruns the edges of the screen is a lot more
frustrating for the user to have to fix than expanding a screen that
actually already fits on the desktop.

>> [snip]

>> What I claim ought to happen is something along the lines of
>> image starts.
>> some code writes to a window.
>> image works out useful things like host screen size(s), any environment or
>> config file or in-image size requests and how to format the content to suit.
>> Host window opens and displays said content.

How about a command-line argument?

       --display-extent [x at y] | [full]

My applications launch headful worker images in the background which
are pre-sized just enough to show a progress bar.  It's exactly what I
want, and they are launched in a rapid-fire succession, so I wouldn't
want any slow or complicated startup code trying to figure out
something something I don't want.  If Such an algorithm would have to
be able to be disabled.


More information about the Squeak-dev mailing list