On Sat, Oct 31, 2020 at 4:18 PM Peter J. Holzer <hjp-pyt...@hjp.at> wrote:
> On 2020-10-31 17:12:36 -0500, 2qdxy4rzwzuui...@potatochowder.com wrote: > > On 2020-10-31 at 19:24:34 +0100, > > "Peter J. Holzer" <hjp-pyt...@hjp.at> wrote: > > > On 2020-10-31 11:58:41 -0500, 2qdxy4rzwzuui...@potatochowder.com > wrote: > > > > 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. > > It does. It's the upper bound. The window may be smaller, but not > larger. > Actually, I think Qt does this (base some parts of layout on the screen's physical size) at some fundamental level. Or so I suspect - I don't know for sure just yet. But if I run a Qt app in TigerVNC (EG keepassxc or an hello world), the app comes up as just a blank window, or it gives a SIGFPE in konsole while sizing the window. And concomitantly xdpyinfo believes that the physical dimensions of the TigerVNC screen are 0x0mm. If I do the same thing over plain ssh+X11 tunneling between the same two hosts, all 3 of those apps work fine, and the dimensions of the screen aren't 0x0. In TigerVNC's partial defense, I'm told that in newer versions of TigerVNC the screen dimensions are no longer 0x0mm. -- https://mail.python.org/mailman/listinfo/python-list
