Hi all,

The default display resolution (1024x768) is now correctly set as of 18167:
http://files.squeak.org/5.2alpha/Squeak5.2alpha-18167-64bit/
http://files.squeak.org/5.2alpha/Squeak5.2alpha-18167-32bit/

If you are interested in the fix, you can find the commit at [1].

Best,
Fabio

[1]
https://github.com/squeak-smalltalk/squeak-app/commit/d83839cba826b83efd930c0823e6695838588c3a

On Mon, Aug 13, 2018 at 10:43 PM Chris Muller <asqueaker at gmail.com> wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180814/3483605a/attachment.html>