<div dir="ltr">Hi all,<div><br></div><div>The default display resolution (1024x768) is now correctly set as of 18167: </div><div><a href="http://files.squeak.org/5.2alpha/Squeak5.2alpha-18167-64bit/">http://files.squeak.org/5.2alpha/Squeak5.2alpha-18167-64bit/</a><br></div><div><a href="http://files.squeak.org/5.2alpha/Squeak5.2alpha-18167-32bit/">http://files.squeak.org/5.2alpha/Squeak5.2alpha-18167-32bit/</a><br></div><div><br></div><div>If you are interested in the fix, you can find the commit at [1].</div><div><br></div><div>Best,</div><div>Fabio</div><div><br></div><div>[1] <a href="https://github.com/squeak-smalltalk/squeak-app/commit/d83839cba826b83efd930c0823e6695838588c3a">https://github.com/squeak-smalltalk/squeak-app/commit/d83839cba826b83efd930c0823e6695838588c3a</a></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Aug 13, 2018 at 10:43 PM Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On further thought, there is one good case for 1024x768 and that is<br>
that it happens to be a darn good default resolution for working in<br>
Squeak -- no resizing necessarily needed.<br>
<br>
Plus, now that 4K seems to becoming a very standard resolution, maybe<br>
we can afford to finally increment from 800x600.  1024 still leaves<br>
enough width for two windows side by side.<br>
<br>
There is still the small device case, but it may be an infrequent occurrence.<br>
<br>
 - Chris<br>
<br>
<br>
<br>
On Mon, Aug 13, 2018 at 1:52 PM, Chris Muller <<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>> wrote:<br>
> Hi guys,<br>
><br>
> May we take a step back and refresh our memory from prior release<br>
> discussions, the use cases concerning the default window size.<br>
> There are hardware considerations and usability considerations.  With<br>
> embedded and IoT, small hardware is here to stay.  There are lots of<br>
> things that can be done in Squeak which will desire a large or small<br>
> screen, one size cannot possibly accommodate everything, but<br>
> generally, the most-accomodating *default image window size* would be<br>
> one that either accomodates small devices (800x600), or otherwise<br>
> full-screen for that device.<br>
><br>
> The "middle ground" 1024x768 is the one that satisfies virtually no<br>
> use cases.  When Squeak would be opened 1024 wide on a small device,<br>
> an image window that overruns the edges of the screen is a lot more<br>
> frustrating for the user to have to fix than expanding a screen that<br>
> actually already fits on the desktop.<br>
><br>
>>> [snip]<br>
><br>
>>> What I claim ought to happen is something along the lines of<br>
>>> image starts.<br>
>>> some code writes to a window.<br>
>>> image works out useful things like host screen size(s), any environment or<br>
>>> config file or in-image size requests and how to format the content to suit.<br>
>>> Host window opens and displays said content.<br>
><br>
> How about a command-line argument?<br>
><br>
>        --display-extent [x@y] | [full]<br>
><br>
> My applications launch headful worker images in the background which<br>
> are pre-sized just enough to show a progress bar.  It's exactly what I<br>
> want, and they are launched in a rapid-fire succession, so I wouldn't<br>
> want any slow or complicated startup code trying to figure out<br>
> something something I don't want.  If Such an algorithm would have to<br>
> be able to be disabled.<br>
><br>
> Best,<br>
>   Chris<br>
<br>
</blockquote></div>