Best way to determine user's screensize?

[Igor Korot]

Hi,

On Sat, Oct 31, 2020, 12:01 PM <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.  Placement of the window is up to the
> window manager, which is also ultimately configured by the user.
>

It is also based on the theme used and the screen DPI


> > ... (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."
>

Agreed.
However, the application may start full screen on the first run and let the
user position and size it saving it for restarting.
Or the app can let the WM position it and again let the user place it
saving the position/size for restart.


> > 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.
> --
> https://mail.python.org/mailman/listinfo/python-list
>