Best way to determine user's screensize?

[2QdxY4RzWzUUiLuE at potatochowder.com]

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.  Placement of the window is up to the
window manager, which is also ultimately configured by the user.

> ... (or at least guaranteed to be smaller than the screen size).

Then how will I *ever* display that 8x10 glossy (with my apologies for
the idiom; 8x10 inches is a "standard" size for a physical desk photo)
of yours truly on my phone?

> 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).  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).

Also, yes, image viewers are different from MUAs.  The latter has to be
much more aware of certain aspects of the display devices(s), but should
still base window sizes on *content* rather than choosing to be "full
screens (plural), because I'm the most important application ever."

> In these cases an application can't use the "natural size": It would be
> bigger than the screen, and depending on the window manager, the user
> might not even be able to resize it because the handles are off-screen.

I remember window managers that let applications open windows that I
can't move.  Aside from a few tricks to "hide" windows, that's a bug.

> It could use some size which is small enough to fit on any screen (how
> large is that? Can you assume 1366x768 these days?). But for most users
> this would be annoying, since they would have to resize the window.

It should request the size it wants, and be prepared to handle not
getting it.  Usually, that means scroll bars.

> (And note that "the user has to do than only once, the second time the
> application can use the saved layout" doesn't hold either: The user may
> have invoked the application on a large desktop monitor the first time,
> but at some point they use the small laptop monitor or a projector.)

Aha!  On this we agree!  :-)

> 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, and not the application inflicting its own ideas on me about
how to use my screen real estate.