Best way to determine user's screensize?

[2QdxY4RzWzUUiLuE at potatochowder.com]

On 2020-10-31 at 19:24:34 +0100,
"Peter J. Holzer" <hjp-python at hjp.at> wrote:

> On 2020-10-31 11:58:41 -0500, 2QdxY4RzWzUUiLuE at potatochowder.com wrote:
> > On 2020-10-31 at 14:37:52 +0100,
> > "Peter J. Holzer" <hjp-python at hjp.at> wrote:
> > 
> > > On 2020-10-31 07:51:38 -0500, 2QdxY4RzWzUUiLuE at potatochowder.com wrote:
> > 
> > > > The intial/default window should be big enough to contain the
> > > > initial/default content, regardless of the configuration of the
> > > > screen(s)/monitor(s).
> > > 
> > > As I already wrote in an answer to Igor, this is only possible if the
> > > initial/default content is of fixed size ...
> > 
> > Bear with me, but I think that that's part of the problem.  Suppose my
> > application edits documents.  The initial content is two buttons, New
> > and Open (I depend on the underlying OS and/or window manager for
> > quitting).  Is the window a fixed size?  No, it's big enough to hold two
> > buttons, sized and scaled based on user supplied defaults, possibly at a
> > lower level, like X11 or Qt.
> 
> In my book that counts as fixed size ...

Then we already have a terminology issue.  :-)

I'll take at least part of the blame because my question as written is
ambiguous:  what I meant to ask was whether or not the application can
specify a predetermined size, in pixels or in millimeters, for that
window.  I believe that the answer is no, because the "correct" size for
that window depends on other things, like the size of the font, the
density of the pixels, user preferences, etc., which can change over
time.  (And my argument remains that said correct size does *not* depend
on the size(s) or the aspect ratio(s) of the screen(s).)

> ... The layout manager can use the information it has (font family and
> size, margins, etc.) compute the sizes of the two buttons, then
> compute the size of the container (possibly using that info to resize
> the buttons), and use that to compute the size of the window. The
> application then requests a window of that size from the window
> manager.

Yep.

> Now consider what happens when the user clicks on that Open button and
> loads the document to be edited. You have to add a text editor widget to
> your window. How large should that be? You know hwo many lines your
> document has, but using a 5000 line text widget for a 5000 line document
> would be ridiculous. You could say "the rest of the window", but your
> window is just large enough for the buttons, so your text widget would
> end up with 0 lines - not very useful. Any fixed size will be too large
> or too small (and while users can usually cope with too small, many of
> them are completely flummoxed by windows which are too large).

The application should pick a size for that widget in lines and columns
of *glyphs*, or a size that matches a potential physical rendering (like
a page in a book) in millimeters, again regardless of the
characteristics of the screen.  Yes, an initial guess may be suboptimal.
Ambitious users can adjust the window and/or their preferences to taste,
and have to recognize that such preferences may depend on other things.
When I switched from a 1920x1080 laptop display to a 3840x2160 laptop
display that was the same size, I had to change a lot of preferences
because applications and font libraries made incorrect assumptions about
pixel density.

I can almost see an application (or a developer) wanting to make that
editing widget, say, 80 characters wide and 2/3 as tall as the screen,
because vertical scroll bars are perfectly acceptable.  Yeah, that'll
look pretty.  Until I (the user) get that wall-size display but I still
want my editing widgets and the text therein to be the same size as my
handwritten notes on real A4 paper.

> Phones are easy: All apps are full-screen (or half-screen, if the OS
> supports that). The app can't request a window size, it has to work
> with what it's got.

That's how video terminals used to be, 80x24, until they weren't.

That's how Apple Macinntosh's used to be, 512x384x1, until they weren't.

You get the idea.  :-)

In Apple's defense, the docs I used in 1984 laid out a completely
heterogeneous display environment, and had instructions for software
that would work when a given window spanned multiple physical display
devices.  I remember how impressed I was when my simple image viewer
worded as advertised when we got our first external color displays.

> > > Very often this is not the case: An image viewer will be used to display
> > > images which are larger than the screen. A MUA may have to display
> > > hundreds of mailboxes, and maybe tens of thousands of mails in a single
> > > mailbox. 
> > 
> > I never claimed it was easy.  Yes, the author of an MUA has to make a
> > guess and a bunch of decisions about a useful default setup (such a set
> > of defaults already appears elsewhere in this thread).
> 
> Aha. And why would be better to "make a guess" than to use information
> available at runtime?

Some information, sure.  Please don't assume that physical pixels or
physical millimeters of display space relate to useful window sizes.

> > But I'm sticking to my story:  that setup should be based on
> > *application domain* objects, like messages and mailboxes, and not
> > size(s) of the screen(s) (in pixels or inches).
> 
> I'm also sticking to my story that those objects are frequently too
> large too display completely. They will need a container with a
> scroll-bar. And then you need to decide how large that container should
> be.

Again, I don't think we're disagreeing.  Our shiny new MUA comes up and
finds 10 million messages in the user's inbox.  Pick a number of
messages, like 10, or 42, and start there.  Don't start with the screen
size and do a bunch of font metric arithmetic to come up with a number
of pixels.

> > It should request the size it wants,
> 
> Yes. The problem of figuring out that size is what we are talking about.
> 
> What I'm reading here is only that the screen size should not be an
> input to the solution even though it's the single hard constraint. 
> 
> What I'm not reading here is how to do it. Except a wishy-washy "let the
> layout manager figure it out", which I don't think it can because it
> doesn't have the necessary information. I'd really like to see some
> code. (See my challenge in another mail. Feel free to do something more
> complicated if you think that's too easy).
> 
> 
> > and be prepared to handle not getting it.  Usually, that means scroll
> > bars.
> 
> Of course. But that's not the problem we are talking about. When the
> size of the window is set from the outside (either because of configured
> constraints or because the user resizes the window) that gives a fixed
> set of constraints to the layout manager. What I'm talking about is when
> the layout manager doesn't have such constraints.

I guess I've always built my GUIs from the bottom up:  put some labels
on a set of radio buttons, put those radio buttons in a vertical list,
put those boxes next to one another, etc.  Macintoshes (it's been a
while), Tk, GTK, Qt, and HTML all seem to create reasonable interfaces.
Or should I say that their layout managers create reasonable interfaces.
If the resulting window is too big for the display, then the user
resizes the window (the trend seems to be that double clicking the title
bar makes the window full screen and then the user can grab the handles)
and the layout manager deals with the resize events.

> > > I am very much a fan of letting layout and window managers do as much
> > > as possible. But I don't think they can do everything. They simply
> > > don't have the necessary information.
> > 
> > I don't think we're disagreeing too much here, either.  IMO, the user
> > should be in control, whether by config file or command line or
> > whatever,
> 
> Config files and command lines are inputs to the application. The
> programmer has to decide what options to accept, what they mean and how
> to process them. As far as this discussion is concerned, they are
> strictly part of the application.

If the user specifies, at runtime, to create a window capable of
displaying M lines of N characters, then M and N are *not* part of the
application.  Presumably, there's an algorithm inside the application
that can calculate useful (or at least usable) values of M and N without
user input; the question is whether that algorithm can/should/must
consume the physical screen size.

> PS: Just for teh lulz, I installed PyQt5 and invoked the designer: It gave
>     me a fixed size window. I also dug up a bit of C#-code I'd written a
>     few years ago. The MainWindow.xaml also specifies a fixed size. You
>     can probably change that in both cases, but it's what you get when
>     you naively use graphical design tools.

Naively using graphical design tools can be hazardous to your users'
health.  :-)