Best way to determine user's screensize?

[Peter J. Holzer]

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

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



> Placement of the window is up to the
> window manager, which is also ultimately configured by the user.

No argument there. I'm talking about determining the size of widgets.


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

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.

(Same for web applications: They can't resize the browser, so they have
fit the layout into available space.)

Desktop Applications OTOH can request a window size (and I think they
even have to, at least with X11, and I think also with Windows). So 
the application must somehow determine how large a window it should
request.


> > 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?

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


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

I never argued that applications should be full screen. Full screen is
easy (see above). The hard part is figuring out a size which is
acceptable for most users.

(Also, yes, image viewers are different from MUAs, but for the topic at
hand they share an important property: There is no single "correct" size
for the thing(s) they display)


> > 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,

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


        hp

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.

-- 
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | hjp at hjp.at         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://mail.python.org/pipermail/python-list/attachments/20201031/9e6a03eb/attachment.sig>