[squeak-dev] Default window size is too small; we should at least increase it a bit and make a preference setting

tim Rowledge tim at rowledge.org
Mon May 16 00:09:41 UTC 2022



> On 2022-05-15, at 1:54 PM, Jakob Reschke <jakres+squeak at gmail.com> wrote:
> 
> Hi Tim,
> 
> I think I have a stupid question, so I should ask it: which windows in Squeak are actually affected in your opinion?

That's not even slightly stupid to ask; the answer is
a) ObjectsTool, because it explicitly uses the RealEstateAgent standardSize in ObjectsTool>>#initializeToStandAlone
b) any openable morph that does not over-ride #initialExtent in some manner.

So for example, quite a lot of morphs implement their own #initialExtent.

And in the latest trunk, quite a few windows multiply some default by the RealEstateAgent scaleFactor.

And Debugger does something quite different and has a class variable to remember a saved size and use that, and it gets updated when you close a debugger for some reason. My experience is that every now and then logic fails and makes the next debugger open at a ridiculously small size.

Some classes have #initialExtent returning a point with no reference to the RealEstateAgent scaleFactor, which is probably sometihng needing fixing. One or two calculate a size based on the best-guess width needed and a multiple of font size - which might mean they respond to the scale factor?

Of the common tools, a hierarchybrowser obeys my suggested preference. So does the transcript, which is actually a good argument for making things a per-class choice, or at least making everything do the scalefactor dance. A workspace does its own sweet thing, and whilst I wouldn't normally want a workspace to be as big as a default browser I'd certainly like it to be bigger than currently set. TestRunner does its own thing and I can't immediately work to where it get the size. A MethodFinder has its own size, a MessageName uses the RealEstateAgent. So do ChangeSorters, but a MonticelloBrowser doesn't. And so on. It's all a bit of a mix.

> 
> I only found a reference to standardSize in the ObjectsTool. Many of the things you can drag out of it are indeed too small, but without checking I would rather suspect that is because they do not respect the new scaling options. The standard sizes of the development tools (Browser, Workspace, Test Runner etc.) seem still adequate to me...

Don't forget direct references to the class variable!

The scaling is not really a relevant issue here (except in that a bunch of things should probably be respecting that factor) because I'm not referring to the overall size of all the UI elements when using high-dpi screens. This is about a lot of the tools simply being so annoying small (in a very likely 1920 at 1080 or larger screen) when they are opened that I have to immediately spend time resizing them. Which gets pretty annoying when it's the two hundredth time that day...

Overall, it's clear that my simple example code is nowhere near a complete answer as yet. Nonetheless, the point-handling preference view stuff should be useful.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Oxymorons: Found missing




More information about the Squeak-dev mailing list