On further thought, there is one good case for 1024x768 and that is
that it happens to be a darn good default resolution for working in
Squeak -- no resizing necessarily needed.

Plus, now that 4K seems to becoming a very standard resolution, maybe
we can afford to finally increment from 800x600.  1024 still leaves
enough width for two windows side by side.

There is still the small device case, but it may be an infrequent occurrence.

 - Chris



On Mon, Aug 13, 2018 at 1:52 PM, Chris Muller <asqueaker at gmail.com> wrote:
> 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.
>
> Best,
>   Chris