On 2020-10-31 11:58:41 -0500, 2qdxy4rzwzuui...@potatochowder.com wrote: > On 2020-10-31 at 14:37:52 +0100, > "Peter J. Holzer" <hjp-pyt...@hjp.at> wrote: > > > On 2020-10-31 07:51:38 -0500, 2qdxy4rzwzuui...@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. |_|_) | | | | | h...@hjp.at | -- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
-- https://mail.python.org/mailman/listinfo/python-list