Smalltalk › Squeak › Squeak - Dev

Project for 'after 5.2 release'

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

25 messages Options

timrowledge

Re: Finishing 5.2 (was Re: Project for 'after 5.2 release')

> On 12-08-2018, at 5:57 PM, Eliot Miranda <[hidden email]> wrote:
>
> Edgar's suggestion of 1024x768 is a sensible one. One could indent by 32@32 to allow for host menu bars etc.

Yes, but IIRC the VMs usually do some OS calls to find the display metrics and then reduce the header-requested size if needed. So *if* the build machines have some setting that is small - as one might imagine on a headless build server? - then you get screwed. I think. My exemplar here is what happens on a Pi when you use vnc to connect to it but the display size preference is unset - the default is a completely useless 320x240 or similar that is too small for the UI tools that would reset that size. Catch 11 (that's Catch 22 when it's half the size you need).

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

K K Subbu

Re: Finishing 5.2 (was Re: Project for 'after 5.2 release')

On Monday 13 August 2018 06:44 AM, tim Rowledge wrote:
> Yes, but IIRC the VMs usually do some OS calls to find the display
> metrics and then reduce the header-requested size if needed. So*if*
> the build machines have some setting that is small - as one might
> imagine on a headless build server? - then you get screwed.

I expect the display plugins to check and recover from out of range
values. The code in
platforms/unix/vm-display-X11/sqUnixX11.c:setWindowSize() does this
check already.

We could generalize this and set the WxH sizes in the header to zero to
mean "let the display plugins pick a reasonable size". The above code
sets the default to 640x480.

Regards .. Subbu

Chris Muller-3

Re: Finishing 5.2 (was Re: Project for 'after 5.2 release')

In reply to this post by Eliot Miranda-2

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@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

Chris Muller-3

Re: Finishing 5.2 (was Re: Project for 'after 5.2 release')

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 <[hidden email]> 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@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

fniephaus

Re: Finishing 5.2 (was Re: Project for 'after 5.2 release')

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 <[hidden email]> 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 <[hidden email]> 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@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