On Sun, 12 Aug 2018 at 1:45 pm, patrick.rein@hpi.uni-potsdam.de wrote:
Hi Edgar,
I have opened up the 5.2 alpha (18167, 64bit, Windows 10) and noticed a few things we might want to fix before the release:
- Without adjusting the window size after opening the image the following
happens: When starting the UI configuration assistant the list of themes and visual settings options is too long. It moves into the "Previous" and "Next" buttons
Marcel and I are aware of that problem, but have yet not found a proper fix. The root problem is that the window size is incorrect. Our CI infrastructure does not have a real display and the virtual one appears to be too small for the dimensions needed to make the UI work correctly. Another fix would be to make the UI 800x600 compatible, not sure if that's an option.
Fabio
- Test failures:
- BrowserTest>>#testAlphabetizeMessageCategories
- BrowserTest>>#testMessageCategoryList
- I have found an issue in the MailSender infrastructure. It is a proper
fault with some methods missing from the class. As I have done the changes previously, I have a fix ready. Should I commit it?
Bests Patrick
I think 5.2 is stable now. I using as base for things I working on. Could have a system on Linux box , use the share directory as link in Mac and open from Mac and save changes. So the .image works from Linux or from Mac remote on same network. I check all bugs reports of 5.0 to now in Mantis for if still relevant. Test on Linux gives only one red . Wish change status to beta, close any new thing and only acept fixes. And all Chris said and more could be 5.3 plan.
Edgar @morplenauta
On 23/07/2018, 23:24, "David T. Lewis" lewis@mail.msen.com wrote:
On Mon, Jul 23, 2018 at 06:54:55PM -0700, Chris Cunningham wrote: Just noticing the number of things that at least one person has flagged for
'after 5.2':
- ProvideAnswerNotification and UIManager (
http://forum.world.st/ProvideAnswerNotification-and-UIManager-td5081488.html
)
- Making ServerDirectory example work (
http://forum.world.st/ServerDirectory-example-login-is-dead-td5061704.html )
- Fixing DateAndTimeLeapTest>>#testAsSeconds (
http://forum.world.st/template/NamlServlet.jtp?macro=search_page&node=12...
query=Some+failing+tests+in+Squeak5.2alpha&n=1294792 )
- Making EToys and
Morphic separation clearer (
http://forum.world.st/The-Inbox-Morphic-hjh-1453-mcz-td5079588.html#a5079826
)
- Make EToys unloadable (
http://forum.world.st/The-Inbox-EToys-hjh-333-mcz-td5079273.html#a5079454 )
- EToysProject (
http://forum.world.st/MorphicProject-subclass-EtoysProject-td4974975i60.html...
5078814 )
- HelpBrowser fixes for Text (
http://forum.world.st/Improving-SqueakToolsHelp-class-gt-gt-fontSizeSummary-...
veals-problems-in-Text-amp-styles-td5081938.html )
Thanks, cbc
That
is a good thing :-) The items in this list are things that are likely
to
introduce instability to trunk if we start working on them right now, so
it is
better to wait for the release before pushing changes into the trunk
for
these issues.
Let's focus on getting the 5.2 release done, including giving
Edgar our full
support to close any issues that are critical to the release.
Once that is
done, we can address the issues that are flagged for follow
up.
Dave
I think 1024x768 is the minimal size for screen ths days, but maybe not
Edgar @morplenauta
On 12/08/2018, 09:02, "Fabio Niephaus" lists@fniephaus.com wrote:
On Sun, 12 Aug 2018 at 1:45 pm, patrick.rein@hpi.uni-potsdam.de wrote:
Hi Edgar,
I have opened up the 5.2 alpha (18167, 64bit, Windows 10) and noticed a few things we might want to fix before the release:
- Without adjusting the window size after opening the image the following
happens: When starting the UI configuration assistant the list of themes and visual settings options is too long. It moves into the "Previous" and "Next" buttons
Marcel and I are aware of that problem, but have yet not found a proper fix. The root problem is that the window size is incorrect. Our CI infrastructure does not have a real display and the virtual one appears to be too small for the dimensions needed to make the UI work correctly. Another fix would be to make the UI 800x600 compatible, not sure if that's an option.
Fabio
- Test failures:
- BrowserTest>>#testAlphabetizeMessageCategories - BrowserTest>>#testMessageCategoryList
- I have found an issue in the MailSender infrastructure. It is a proper
fault with some methods missing from the class. As I have done the changes previously, I have a fix ready. Should I commit it?
Bests Patrick
On 12-08-2018, at 5:02 AM, Fabio Niephaus lists@fniephaus.com wrote:
Marcel and I are aware of that problem, but have yet not found a proper fix. The root problem is that the window size is incorrect. Our CI infrastructure does not have a real display and the virtual one appears to be too small for the dimensions needed to make the UI work correctly. Another fix would be to make the UI 800x600 compatible, not sure if that's an option.
I'm not sure if it's still in there (really, it should never have been but that's a different story) but the image header used to have some data specifying a window size. You *could* do a little header manipulation to set it to whatever size you think appropriate post-save.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Can easily be confused with facts.
On Sun, Aug 12, 2018 at 7:24 PM tim Rowledge tim@rowledge.org wrote:
On 12-08-2018, at 5:02 AM, Fabio Niephaus lists@fniephaus.com wrote:
Marcel and I are aware of that problem, but have yet not found a proper
fix. The root problem is that the window size is incorrect. Our CI infrastructure does not have a real display and the virtual one appears to be too small for the dimensions needed to make the UI work correctly. Another fix would be to make the UI 800x600 compatible, not sure if that's an option.
I'm not sure if it's still in there (really, it should never have been but that's a different story) but the image header used to have some data specifying a window size. You *could* do a little header manipulation to set it to whatever size you think appropriate post-save.
It's still there, but I'd like to avoid manipulating the header manually. The VM should do the right thing anyway...
Fabio
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Can easily be confused with facts.
On 12-08-2018, at 1:33 PM, Fabio Niephaus lists@fniephaus.com wrote:
On Sun, Aug 12, 2018 at 7:24 PM tim Rowledge tim@rowledge.org wrote:
[snip]
I'm not sure if it's still in there (really, it should never have been but that's a different story) but the image header used to have some data specifying a window size. You *could* do a little header manipulation to set it to whatever size you think appropriate post-save.
It's still there, but I'd like to avoid manipulating the header manually. The VM should do the right thing anyway...
Well, now that is an interesting can of annelids to access. I've long argued that there should be no need for that info in the header because there should be no window getting opened until and unless the image code requests it. The RISC OS vm for example only opens the main window if a copyBits writes something to the Display form; that way a headless system needs no silly command line flag etc - just have your image not write to a window! I mean, wow, how innovative is that?
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.
Since we can't do all that this week, I suspect that fudging the image header data is probably the least-worst solution for now. It might be possible to set the build machines to pretend to have a suitable window size in some way but you're probably looking at some time-consuming digging to find out how to get it right for each platform.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "#define QUESTION ((bb) || !(bb)) - Shakespeare."
On Sun, Aug 12, 2018 at 3:15 PM, tim Rowledge tim@rowledge.org wrote:
On 12-08-2018, at 1:33 PM, Fabio Niephaus lists@fniephaus.com wrote:
On Sun, Aug 12, 2018 at 7:24 PM tim Rowledge tim@rowledge.org wrote:
[snip]
I'm not sure if it's still in there (really, it should never have been
but that's a different story) but the image header used to have some data specifying a window size. You *could* do a little header manipulation to set it to whatever size you think appropriate post-save.
It's still there, but I'd like to avoid manipulating the header
manually. The VM should do the right thing anyway...
Well, now that is an interesting can of annelids to access. I've long argued that there should be no need for that info in the header because there should be no window getting opened until and unless the image code requests it. The RISC OS vm for example only opens the main window if a copyBits writes something to the Display form; that way a headless system needs no silly command line flag etc - just have your image not write to a window! I mean, wow, how innovative is that?
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.
+1
Since we can't do all that this week, I suspect that fudging the image header data is probably the least-worst solution for now.
+1
It might be possible to set the build machines to pretend to have a suitable window size in some way but you're probably looking at some time-consuming digging to find out how to get it right for each platform.
Edgar's suggestion of 1024x768 is a sensible one. One could indent by 32@32 to allow for host menu bars etc.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim "#define QUESTION ((bb) || !(bb)) - Shakespeare."
_,,,^..^,,,_ best, Eliot
On 12-08-2018, at 5:57 PM, Eliot Miranda eliot.miranda@gmail.com 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; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Sanitary landfill
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
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
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@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@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
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/d83839cba826b83efd930c...
On Mon, Aug 13, 2018 at 10:43 PM Chris Muller asqueaker@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@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@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
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
Edgar J. De Cleene -
Eliot Miranda -
Fabio Niephaus -
K K Subbu -
tim Rowledge