Re: GUI: I am also looking for a nudge into the best (GUI) direction.

[Barry Scott]

> On 29 Oct 2020, at 15:54, flaskee via Python-list  
> wrote:
> 
> Hello!
> 
> I've been reading the GUI toolkit posts.
> 
> If anyone can give me a push in the right python direction on
> my needs, I'd be grateful.
> 
> This is for business applications, not games.
> (but if a game toolkit fits...)
> 

I choose to use PyQt5 for my apps that run on Linux, macOS and Windows.

You can see my apps code if you wish to see working examples:

https://barrys-emacs.org 
https://scm-workbench.barrys-emacs.org/ 


In the past I had used wxPython but it had too many problems and it was cheaper 
for
me to port in PyQt5 then have to carry a lot of platform specific workarounds.

PyQt5 can target iOS and android.

With PyQt5 I can develop on Linux and have high confidence that the code will 
run the
same way on macOS and Windows.

Barry

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to determine user's screensize?

[Peter J. Holzer]

On 2020-10-30 20:08:35 -0700, jf...@ms4.hinet.net wrote:
> What's wrong the OP's question? Why can't just answer it?

Igor already answered it: There is no best way in Python, because it
depends on the framework (and there are many frameworks).

hp

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

Re: Best way to determine user's screensize?

[Peter J. Holzer]

On 2020-10-30 19:18:22 -0500, Igor Korot wrote:
> On Fri, Oct 30, 2020 at 6:59 PM Peter J. Holzer  wrote:
> > On 2020-10-31 10:02:12 +1100, Chris Angelico wrote:
> > > I add my voice to those who detest applications that think they know
> > > best and decide that they own the entire screen.
> >
> > So, assuming the user is invoking the application for the first time,
> > how should an application determine how much of the screen it should
> > use? It has to make some choice, and any hard-coded value is almost
> > certainly wrong. So why should an application not use the screen size as
> > one factor?
> 
> It is not up to application.
> It is up to the underlying layout system to decide.

This only works if all the GUI elements are of fixed size. 

If you are writing a MUA, for example, there are several elements which
are essentially of arbitrary size: A list or tree of mailboxes. A list
(or forest) of mails in the current mailbox. A pane to display the
current mail. To size these properly you have to know what kind of
information is going to be displayed. Depending on the screen size it
may be better to only show one of them at a time. The application
programmer knows this. The layout system doesn't. This should also be
configurable by the user, which again means that the application has to
a) provide a configuration UI and b) has to be able to set the layout
the way the user configured it.

Layout systems are important and useful. But they are tools, they can't
do everything by themselves. In the end the application programmer has
to decide how to use them.

hp

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

Re: Best way to determine user's screensize?

[Peter J. Holzer]

On 2020-10-31 12:30:43 +1100, Chris Angelico wrote:
> On Sat, Oct 31, 2020 at 10:57 AM Peter J. Holzer  wrote:
> > On 2020-10-31 10:02:12 +1100, Chris Angelico wrote:
> > > On Sat, Oct 31, 2020 at 9:55 AM flaskee via Python-list
> > >  wrote:
> > > > I have done all of this resizing and layout stuff before.
> > > >
> > > > I just ignored the grouchy user with the hate over me wanting 
> > > > screensize.
> > > > (every list has one of those types, eh? :-)
> > > >
> > > > Screensize, in part, determines the aspect ratio calcs to dynamically
> > > > resize and place the components on the screen.
> > > >
> > >
> > > So what would you do if it turns out that my screen is 5440 x 2104?
> > > That's what mine is right now.
> >
> > That depends on the application.
> >
> > If for example the application is in image viewer and the image to be
> > viewed is 4576x3432 pixels large, that wouldn't fit on the screen.
> > Assuming 200 pixels of vertical chrome (title bar, window borders, menu
> > bar and/or buttons), the image would have to be resized to (at most)
> > 2539x1904 pixels. So the window would be sized to accommodate that.
> >
> > (If you use a multi-screen setup, the calculation should be based on
> > the current screen, of course, not on the combined size of all screens)
> >
> 
> But what is the "current screen"? That's the problem.

The one where the window manager decided to put the window?

(Ok, there may be a bit of a catch-22 here: You might want that
information before actually creating the window, but the window manager
can only place the window once it's created. Plus the placement might
depend on the size.)

> MANY applications (mostly games) decide to put themselves on monitor
> #4 and size themselves according to monitor #1, or some other
> mismatching.

Well, that's obviously a bug. (Presumably the programmer didn't expect
there to be more than one screen, or at least not screens of different
sizes.)

> Or, I alt-tab away from something, come back in, and it resizes itself
> to a different screen size.
> 
> There is no valid way for an application to read my mind and size
> itself. Attempting to query my screen size seems to just make things
> worse in a lot of situations.

You still haven't answered the question: Where should the initial window
size come from? Does your window manager tell the application how large
a window should be? And if it does, can you as a user configure that? I
don't think mine (xfce) does that. (I guess tiling WMs generally do
that, but I've never used one.)

hp

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

Re: Best way to determine user's screensize?

[Peter J. Holzer]

On 2020-10-30 20:47:50 -0400, songbird wrote:
> Chris Angelico wrote:
> > I add my voice to those who detest applications that think they know
> > best and decide that they own the entire screen. It is incredibly
> > annoying.
> 
>   do you object to a window being put in the approximate
> center of the screen?

Yes, I do. That puts all the windows on top of each other and I have to
move them to a better position.

I have configured my window manager to place new windows so that the
overlap with existing windows is minimised.

hp

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

Re: GUI: I am also looking for a nudge into the best (GUI) direction.

[Betty Hollinshead]

On Saturday, 31 October 2020 at 08:36:48 UTC, Barry Scott wrote:
> > On 29 Oct 2020, at 15:54, flaskee via Python-list  
> > wrote: 
> > 
> > Hello! 
> > 
> > I've been reading the GUI toolkit posts. 
> > 
> > If anyone can give me a push in the right python direction on 
> > my needs, I'd be grateful. 
> > 
> > This is for business applications, not games. 
> > (but if a game toolkit fits...) 
> >
> I choose to use PyQt5 for my apps that run on Linux, macOS and Windows. 
> 
> You can see my apps code if you wish to see working examples: 
> 
> https://barrys-emacs.org  
> https://scm-workbench.barrys-emacs.org/ 
>  
> 
> In the past I had used wxPython but it had too many problems and it was 
> cheaper for 
> me to port in PyQt5 then have to carry a lot of platform specific 
> workarounds. 
> 
> PyQt5 can target iOS and android. 
> 
> With PyQt5 I can develop on Linux and have high confidence that the code will 
> run the 
> same way on macOS and Windows. 
> 
> Barry
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: GUI: I am also looking for a nudge into the best (GUI) direction.

[Betty Hollinshead]

On Saturday, 31 October 2020 at 08:36:48 UTC, Barry Scott wrote:
> > On 29 Oct 2020, at 15:54, flaskee via Python-list  
> > wrote: 
> > 
> > Hello! 
> > 
> > I've been reading the GUI toolkit posts. 
> > 
> > snip
> >
> Barry

Suggest you look at Glade and pure Python3
Works well on Linux (Fedora here)
No idea about other platforms

GUI Design: Glade
GUI designer which produces an XML description of the target GUI (e.g. 
mainwin.glade)

Python3 code outline
from gi.repository import GObject, Gio, Gdk, Gtk
...
class AppWindow(object):
def __init__():
...
try:
   builder = Gtk.Builder.new_from_file("mainwin.glade")
   builder.connect_signals(self)
except GObject.GError:
   print("Error reading GUI file")
   raise

There is identical support for using the Glade xml in a C application (but 
Python is easier!).
Liz
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to determine user's screensize?

[2QdxY4RzWzUUiLuE]

On 2020-10-31 at 13:02:03 +0100,
"Peter J. Holzer"  wrote:

> On 2020-10-31 12:30:43 +1100, Chris Angelico wrote:

> > There is no valid way for an application to read my mind and size
> > itself. Attempting to query my screen size seems to just make things
> > worse in a lot of situations.

> You still haven't answered the question: Where should the initial
> window size come from? Does your window manager tell the application
> how large a window should be? And if it does, can you as a user
> configure that? I don't think mine (xfce) does that. (I guess tiling
> WMs generally do that, but I've never used one.)

The intial/default window should be big enough to contain the
initial/default content, regardless of the configuration of the
screen(s)/monitor(s).  "The GUI," whether it's something near the
bottom, like X11, or something more complicated, like GTK or Qt, should
have the information and/or the API to make the widgets usable and the
text readable, possibly based on user configuration (e.g., I like 6
point type on my 288dpi laptop display; other people might like 12 point
type on their 72dpi big screen monitor).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to determine user's screensize?

[Chris Angelico]

On Sat, Oct 31, 2020 at 11:53 PM <2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> On 2020-10-31 at 13:02:03 +0100,
> "Peter J. Holzer"  wrote:
>
> > On 2020-10-31 12:30:43 +1100, Chris Angelico wrote:
>
> > > There is no valid way for an application to read my mind and size
> > > itself. Attempting to query my screen size seems to just make things
> > > worse in a lot of situations.
>
> > You still haven't answered the question: Where should the initial
> > window size come from? Does your window manager tell the application
> > how large a window should be? And if it does, can you as a user
> > configure that? I don't think mine (xfce) does that. (I guess tiling
> > WMs generally do that, but I've never used one.)
>
> The intial/default window should be big enough to contain the
> initial/default content, regardless of the configuration of the
> screen(s)/monitor(s).  "The GUI," whether it's something near the
> bottom, like X11, or something more complicated, like GTK or Qt, should
> have the information and/or the API to make the widgets usable and the
> text readable, possibly based on user configuration (e.g., I like 6
> point type on my 288dpi laptop display; other people might like 12 point
> type on their 72dpi big screen monitor).

This. The window manager gets information from the internal layout
manager, but the application itself shouldn't care. I should be able
to build a window by saying "it should have a notebook, and that
notebook should have a label saying Name and an input big enough for
20 characters, and below that a label saying Class and a drop-down
with options Wizard, Cleric, Fighter, etc, etc, etc, etc". At no point
should pixel sizes or screen sizes be within the scope of my
application.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to determine user's screensize?

[Peter J. Holzer]

On 2020-10-31 07:51:38 -0500, 2qdxy4rzwzuui...@potatochowder.com wrote:
> On 2020-10-31 at 13:02:03 +0100,
> "Peter J. Holzer"  wrote:
> > On 2020-10-31 12:30:43 +1100, Chris Angelico wrote:
> > > There is no valid way for an application to read my mind and size
> > > itself. Attempting to query my screen size seems to just make things
> > > worse in a lot of situations.
> 
> > You still haven't answered the question: Where should the initial
> > window size come from? Does your window manager tell the application
> > how large a window should be? And if it does, can you as a user
> > configure that? I don't think mine (xfce) does that. (I guess tiling
> > WMs generally do that, but I've never used one.)
> 
> 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 (or at least guaranteed to be
smaller than the screen size). 

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. 

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.

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.

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

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.

hp

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

Re: Best way to determine user's screensize?

[Mats Wichmann]

On 10/30/20 6:47 PM, songbird wrote:
> Chris Angelico wrote:
> ...
>> I add my voice to those who detest applications that think they know
>> best and decide that they own the entire screen. It is incredibly
>> annoying.
> 
>   do you object to a window being put in the approximate
> center of the screen?

Absolutely!  I'm fighting that on a system which, after an update,
insists on opening new terminal windows centered - some recent policy
change is now doing that instead of where the same thing was placed the
last time it was open (I assume I'll find the knob for that eventually).
 As others have said, there's no one-size-fits-all; on a big screen you
certainly don't want the same things as on a phone, where "take over the
whole screen" might indeed be the only thing that makes sense.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Command errored out with exit status 1: python setup.py egg_info Check the logs for full command output.

[Mats Wichmann]

On 10/30/20 1:38 PM, Gian_Xatzak. wrote:
>When I tried to download  matplotlib, it show me that message in the end:
> 
> 
> 
>ERROR: Command errored out with exit status 1: python setup.py egg_info
>Check the logs for full command output.
> 
> 
> 
>*I have Windows 10, Python3.8.6(64bit)

TL;DR - don't be in such a hurry to upgrade to 3.9.

I'll bet the full errors would show pip is calling setup on the sdist
version because you've updated to 3.9 and  there's no wheel for 3.9 for
matplotlib yet.  The fallback, compilation, usually fails for Windows
users, although you could attempt to follow the project's instructions
for getting a build environment set up correctly.  When various projects
which have binary wheels release their versions supporting a new Python
release is up to them; this happens every time a new X in the Python 3.X
series is released.

You can check for the presence of binary wheels for your system and
Python version by querying for the package on pypi.org and clicking to
see the downloadable files.

There is a place you can get unofficial builds of many popular packages
early on, but I kind of don't like to recommend people use "unofficial"
builds. With suitable cautions, you can look there if you want (you'd be
looking for names containing 'cp39')

https://www.lfd.uci.edu/~gohlke/pythonlibs/#matplotlib


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to determine user's screensize?

[Grant Edwards]

On 2020-10-31, songbird  wrote:
> Chris Angelico wrote:
> ...
>> I add my voice to those who detest applications that think they know
>> best and decide that they own the entire screen. It is incredibly
>> annoying.
>
> do you object to a window being put in the approximate
> center of the screen?

YES. I've configured my window manager so windows start up where I
want them to start up. It's none of the application's business where
it's window is.

When developing an application, try to remember IT'S NOT YOUR
COMPUTER.


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to determine user's screensize?

[Grant Edwards]

On 2020-10-30, Peter J. Holzer  wrote:

> So, assuming the user is invoking the application for the first time,
> how should an application determine how much of the screen it should
> use?

You arrange the widgets the way you want them using the user's
settings for the toolkit and let the sizers figure out the size.

> It has to make some choice, and any hard-coded value is almost
> certainly wrong.

Definitely, absolutely wrong.

> So why should an application not use the screen size as
> one factor?

Because it's got nothing to do with the appropriate window size for
the application?

Why should the application start out any larger just because the
screen is larger?

--
Grant




-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to determine user's screensize?

[Grant Edwards]

On 2020-10-30, flaskee via Python-list  wrote:

> In odd screen sizes or multi-monitor situations,
> I make the best guess,

Stop guessing. Let the window manager, and layout algorithm do the
jobs for which they were designed.

> but allow the user to alter things, via preferences.

If you want to remember when a user resizes the application and
re-open with that same geometry, that's OK. Doin't it "via
preferences" is right out.


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to determine user's screensize?

[Grant Edwards]

On 2020-10-31, Chris Angelico  wrote:
>
>> do you object to a window being put in the approximate
>> center of the screen?
>>
>
> If that's where my window manager chooses to put it, great! The
> application just says "I want a window of this size"

But let the widget/toolkit layout engine figure out the size. The
application developer should just specify what widgets are needed and
how they are to be arranged. The developer should _not_ be specifying
window sizes.

> and the window manager decides where that should go. The application
> doesn't.

Exactly.  Don't try to override the window manager if I've configured
it to open your application in at certain location and/or a certain
window size. It's my computer.


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to determine user's screensize?

[Grant Edwards]

On 2020-10-30, flaskee via Python-list  wrote:

> Funny thing about people who bitch and complain
> and offer no help,

Layout your widgets using appropriate sizers and constraints, and then
let them and the window manager do their jobs. You shouldn't be
messing about with window sizes and locations, or you end up with
abominations like Visual Basic programmers used to produce in the bad
old days.




-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to determine user's screensize?

[Grant Edwards]

On 2020-10-31, Peter J. Holzer  wrote:

> Very often this is not the case: An image viewer will be used to
> display images which are larger than the screen.

Tell the image widget what image you want to display, and then forget
about it. Let the toolkit and window manager do their jobs.

> A MUA may have to display hundreds of mailboxes, and maybe tens of
> thousands of mails in a single mailbox.

No. It doesn't. It has to display a tree widget that shows N items and
holds tens of thousands of items, or a scrolling list widget than
shows M items and holds tens of thousands of items.  Pick reasonable
initial default values for N,M and then let the window manager and
user do the right thing.

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

They do in a well-written application.

--
Gran

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to determine user's screensize?

[Terry Reedy]

On 10/30/2020 12:05 PM, Grant Edwards wrote:

On 2020-10-30, flaskee via Python-list  wrote:


What is the best approach to determining the user's available
screensize, when they open your python application?


IDLE, based on tkinter based on tcl/tk has a feature to vertically zoom 
an editor window to the full usable height, which is vertical pixel - 
top and or bottom taskbar pixels.  The only way we found to do that is 
to go full screen, get the window size, and revert to previous size. 
Not foolproof (or rather, not expert-proof), but a best-known effor.



All you need to know is how big your application window is. The user's
available screen size is none of your business.


See above.

--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

RE: Can property getters and setters have additional arguments?

[pjfarley3]

Apologies if you receive two copies of this message, but I sent it almost 10
hours ago and still have not seen it come back to me or appear in the
archives.

I would appreciate any help or RTFM you can provide.

Peter

> -Original Message-
> From: Peter Farley
> Sent: Saturday, October 31, 2020 1:17 AM
> To: 'python-list@python.org' 
> Subject: Can property getters and setters have additional arguments?
> 
> I asked this question over on the python-forum-io group but haven't gotten
> much in the way of answers.  I hope someone here can advise me.
> 
> I am trying to implement getters and setters in a class using a numpy
array as the
> base instance value, but I am not able to pass an array index argument to
the
> getter function (and probably not to the setter function, but it never
gets that
> far).
> 
> This is all happening on a Win10x64 system using python 3.8.5.
> 
> Please help me understand whether what I tried to code here is even
possible.
> 
> Peter
> 
> The code is as follows:
> 
>  cut here 
> import numpy as np
> 
> class Matrix:
> def __init__(self, msize):
> self.msize = msize
> self.mvalues = np.full([msize + 2, msize + 2, msize + 2], -1,
>dtype=np.int32)
> self.mvalues[1:-1, 1:-1, 1:-1] = 0
> self.visited = np.zeros([msize + 2, msize + 2, msize + 2],
> dtype=np.int32)
> 
> @property
> def visits(self, coord):
> return self.visited[coord[0], coord[1], coord[2]]
> 
> @visits.setter
> def incr_visits(self, coord, incr):
> self.visited[coord[0], coord[1], coord[2]] += incr
> 
> 
> def Coord(x, y, z):
> return np.full([3,], (x, y, z), dtype=np.int32)
> 
> mycoord = Coord(1, 2, 3)
> print("mycoord={}".format(mycoord))
> 
> mygal = Matrix(10)
> print("Before set:{}".format(mygal.visits(mycoord)))
> 
> mygal.incr_visits(mycoord, 10)
> print("After  set:{}".format(mygal.visits(mycoord)))
>  cut here 
> 
> The output I get is as follows:
> 
>  output 
> mycoord=[1 2 3]
> Traceback (most recent call last):
>   File "C:\Users\MyUser\Test\clstest4.py", line 28, in 
> print("Before set:{}".format(mygal.visits(mycoord)))
> TypeError: visits() missing 1 required positional argument: 'coord'
>  output 
> 


-- 
https://mail.python.org/mailman/listinfo/python-list

Can property getters and setters have additional arguments?

[pjfarley3]

I asked this question over on the python-forum-io group but haven't gotten
much in the way of answers.  I hope someone here can advise me.

I am trying to implement getters and setters in a class using a numpy array
as the base instance value, but I am not able to pass an array index
argument to the getter function (and probably not to the setter function,
but it never gets that far).

This is all happening on a Win10x64 system using python 3.8.5.

Please help me understand whether what I tried to code here is even
possible.

Peter

The code is as follows:

 cut here 
import numpy as np
 
class Matrix:
def __init__(self, msize):
self.msize = msize
self.mvalues = np.full([msize + 2, msize + 2, msize + 2], -1,
   dtype=np.int32)
self.mvalues[1:-1, 1:-1, 1:-1] = 0
self.visited = np.zeros([msize + 2, msize + 2, msize + 2],
dtype=np.int32)
 
@property
def visits(self, coord):
return self.visited[coord[0], coord[1], coord[2]]
 
@visits.setter
def incr_visits(self, coord, incr):
self.visited[coord[0], coord[1], coord[2]] += incr
 
 
def Coord(x, y, z):
return np.full([3,], (x, y, z), dtype=np.int32)
 
mycoord = Coord(1, 2, 3)
print("mycoord={}".format(mycoord))
 
mygal = Matrix(10)
print("Before set:{}".format(mygal.visits(mycoord)))
 
mygal.incr_visits(mycoord, 10)
print("After  set:{}".format(mygal.visits(mycoord)))
 cut here 

The output I get is as follows:

 output 
mycoord=[1 2 3]
Traceback (most recent call last):
  File "C:\Users\MyUser\Test\clstest4.py", line 28, in 
print("Before set:{}".format(mygal.visits(mycoord)))
TypeError: visits() missing 1 required positional argument: 'coord'
 output 



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to determine user's screensize?

[Chris Angelico]

On Sun, Nov 1, 2020 at 3:35 AM Grant Edwards  wrote:
>
> On 2020-10-31, Chris Angelico  wrote:
> >
> >> do you object to a window being put in the approximate
> >> center of the screen?
> >>
> >
> > If that's where my window manager chooses to put it, great! The
> > application just says "I want a window of this size"
>
> But let the widget/toolkit layout engine figure out the size. The
> application developer should just specify what widgets are needed and
> how they are to be arranged. The developer should _not_ be specifying
> window sizes.

Correct. There's effectively a negotiation up and down the chain where
the application itself doesn't care one iota what a "pixel" is, and
its window's size is defined by content. A lot of sizes will be
defined in terms of text ("I want an entry field big enough for 40
characters", which is an approximation of course, but a useful one),
and others might be defined by other things, but the precise pixel
dimensions are up to the layout engine - which should be using native
widgets, which effectively puts the control back in the hands of the
window manager.

And putting control in the hands of the window manager means putting
it in the hands of the user. The user can configure his/her computer
completely. It is not the application's computer, it is the user's.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to determine user's screensize?

[Grant Edwards]

On 2020-10-31, Random832  wrote:
> On Fri, Oct 30, 2020, at 20:18, Igor Korot wrote:
>> Hi,
>> 
>> On Fri, Oct 30, 2020 at 6:59 PM Peter J. Holzer  wrote:
>> > So, assuming the user is invoking the application for the first time,
>> > how should an application determine how much of the screen it should
>> > use? It has to make some choice, and any hard-coded value is almost
>> > certainly wrong. So why should an application not use the screen size as
>> > one factor?
>> 
>> It is not up to application.
>> It is up to the underlying layout system to decide.
>
> What is a "layout system"?

In a GUI toolkit, it's a set of constructs that lets you specify the
relative positions of widgets, which widgets are flexible and which
aren't, and so on. The layout system then determines the sizes of
widgets and windows.

> I don't think such a thing exists, in
> general, for positioning top-level windows on major platforms.

On Linux/Unix, there certainly is. It's called a window manager. There
are many to chose from, and they have various user-configurable
settings that allow the user to control the sizes and positions of
top-level windows.

> Each application has to write its own,

Nonsense.

> and it is reasonable for the layout system itself [which, as I've
> pointed out, is part of the application - there is no such thing as
> a system service] to need access to this information.

There are two levels of layout system services: the GUI
toolkit/framework and the window manager.





-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to determine user's screensize?

[Ethan Furman]

On 10/30/20 6:24 PM, Grant Edwards wrote:

On 2020-10-30, flaskee via Python-list wrote:



but allow the user to alter things, via preferences.


If you want to remember when a user resizes the application and
re-open with that same geometry, that's OK. Doin't it "via
preferences" is right out.


Why is using preferences "right out"?  Is that not the user saying where they 
want the app to be positioned?

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to determine user's screensize?

[Grant Edwards]

On 2020-10-31, Peter J. Holzer  wrote:

> You still haven't answered the question: Where should the initial window
> size come from?

The GUI toolkit used by the application calculates a "desired" window
size based on the widgets and layout constraints. That desire is
passed to the window manager, and the window manager then decides
what the winow size is.

> Does your window manager tell the application how large a window
> should be?

Yes.

> And if it does, can you as a user configure that?

Yes.

> I don't think mine (xfce) does that. (I guess tiling WMs generally
> do that, but I've never used one.)

--
Grant



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Can property getters and setters have additional arguments?

[Chris Angelico]

On Sun, Nov 1, 2020 at 3:46 AM  wrote:
>
> I asked this question over on the python-forum-io group but haven't gotten
> much in the way of answers.  I hope someone here can advise me.
>
> I am trying to implement getters and setters in a class using a numpy array
> as the base instance value, but I am not able to pass an array index
> argument to the getter function (and probably not to the setter function,
> but it never gets that far).
>

I'm not sure why you're using getters and setters there, but I think
what you want is best handled with a simple member function. Try to
keep it really really simple and it'll almost certainly be correct.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: GUI: I am also looking for a nudge into the best (GUI) direction.

[Igor Korot]

Hi, Barry,

On Sat, Oct 31, 2020, 3:39 AM Barry Scott  wrote:

>
>
> > On 29 Oct 2020, at 15:54, flaskee via Python-list <
> python-list@python.org> wrote:
> >
> > Hello!
> >
> > I've been reading the GUI toolkit posts.
> >
> > If anyone can give me a push in the right python direction on
> > my needs, I'd be grateful.
> >
> > This is for business applications, not games.
> > (but if a game toolkit fits...)
> >
>
> I choose to use PyQt5 for my apps that run on Linux, macOS and Windows.
>
> You can see my apps code if you wish to see working examples:
>
> https://barrys-emacs.org 
> https://scm-workbench.barrys-emacs.org/ <
> https://scm-workbench.barrys-emacs.org/>
>
> In the past I had used wxPython but it had too many problems and it was
> cheaper for
> me to port in PyQt5 then have to carry a lot of platform specific
> workarounds.
>
> PyQt5 can target iOS and android.
>
> With PyQt5 I can develop on Linux and have high confidence that the code
> will run the
> same way on macOS and Windows.
>

Qt does not use native controls on 3 major platforms and so is out of the
question...

Thank you.


> Barry
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to determine user's screensize?

[2QdxY4RzWzUUiLuE]

On 2020-10-31 at 14:37:52 +0100,
"Peter J. Holzer"  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.  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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to determine user's screensize?

[Igor Korot]

Hi,

On Sat, Oct 31, 2020, 8:00 AM Chris Angelico  wrote:

> On Sat, Oct 31, 2020 at 11:53 PM <2qdxy4rzwzuui...@potatochowder.com>
> wrote:
> >
> > On 2020-10-31 at 13:02:03 +0100,
> > "Peter J. Holzer"  wrote:
> >
> > > On 2020-10-31 12:30:43 +1100, Chris Angelico wrote:
> >
> > > > There is no valid way for an application to read my mind and size
> > > > itself. Attempting to query my screen size seems to just make things
> > > > worse in a lot of situations.
> >
> > > You still haven't answered the question: Where should the initial
> > > window size come from? Does your window manager tell the application
> > > how large a window should be? And if it does, can you as a user
> > > configure that? I don't think mine (xfce) does that. (I guess tiling
> > > WMs generally do that, but I've never used one.)
> >
> > The intial/default window should be big enough to contain the
> > initial/default content, regardless of the configuration of the
> > screen(s)/monitor(s).  "The GUI," whether it's something near the
> > bottom, like X11, or something more complicated, like GTK or Qt, should
> > have the information and/or the API to make the widgets usable and the
> > text readable, possibly based on user configuration (e.g., I like 6
> > point type on my 288dpi laptop display; other people might like 12 point
> > type on their 72dpi big screen monitor).
>
> This. The window manager gets information from the internal layout
> manager, but the application itself shouldn't care. I should be able
> to build a window by saying "it should have a notebook, and that
> notebook should have a label saying Name and an input big enough for
> 20 characters, and below that a label saying Class and a drop-down
> with options Wizard, Cleric, Fighter, etc, etc, etc, etc". At no point
> should pixel sizes or screen sizes be within the scope of my
> application.
>

Amen to that, Chris.

Thank you.


> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to determine user's screensize?

[Igor Korot]

Hi,

On Sat, Oct 31, 2020, 11:33 AM Grant Edwards 
wrote:

> On 2020-10-31, songbird  wrote:
> > Chris Angelico wrote:
> > ...
> >> I add my voice to those who detest applications that think they know
> >> best and decide that they own the entire screen. It is incredibly
> >> annoying.
> >
> > do you object to a window being put in the approximate
> > center of the screen?
>
> YES. I've configured my window manager so windows start up where I
> want them to start up. It's none of the application's business where
> it's window is.
>
> When developing an application, try to remember IT'S NOT YOUR
> COMPUTER.
>

And its not you that will use an application. So whatever works for you may
not work for user.

Thank you.


>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to determine user's screensize?

[Peter J. Holzer]

On 2020-10-31 01:20:39 -, Grant Edwards wrote:
> On 2020-10-30, Peter J. Holzer  wrote:
> 
> > So, assuming the user is invoking the application for the first time,
> > how should an application determine how much of the screen it should
> > use?
> 
> You arrange the widgets the way you want them using the user's
> settings for the toolkit and let the sizers figure out the size.

Ok. I am trying one last time.

Consider a very minimalistic image viewer. It has a menu bar at the top
and shows one image. The path to the image may be passed as sys.argv[1],
in which case it should be immediately displayed. The image should be
displayed in "natural" size but must be scaled down if it doesn't fit.


How do you do that?

You may use any framework, preferrably (since this is a Python group)
a cross-platform framework usable from Python.

hp

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

Re: Best way to determine user's screensize?

[Igor Korot]

Hi,

On Sat, Oct 31, 2020, 8:40 AM Peter J. Holzer  wrote:

> On 2020-10-31 07:51:38 -0500, 2qdxy4rzwzuui...@potatochowder.com wrote:
> > On 2020-10-31 at 13:02:03 +0100,
> > "Peter J. Holzer"  wrote:
> > > On 2020-10-31 12:30:43 +1100, Chris Angelico wrote:
> > > > There is no valid way for an application to read my mind and size
> > > > itself. Attempting to query my screen size seems to just make things
> > > > worse in a lot of situations.
> >
> > > You still haven't answered the question: Where should the initial
> > > window size come from? Does your window manager tell the application
> > > how large a window should be? And if it does, can you as a user
> > > configure that? I don't think mine (xfce) does that. (I guess tiling
> > > WMs generally do that, but I've never used one.)
> >
> > 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 (or at least guaranteed to be
> smaller than the screen size).
>

Any control at any given moment has a fixed size.
If I can't set the initial size of the control in the appropriate layout
system, then this is not a layout system.
After the initial size is set it is up to the application to properly give
the aspect ratio, font sizes, etc when the application is moved between the
windows, resized, or DPI has changed, etc.


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

What is natural size? Please define this term.


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

This is exactly my point.
If the underlying toolkit is smart enough and the layout system is good
then it won't matter.


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

Of course not.
Thats why software devs are paid big money to do proper designs. 😀

Thank you.


> hp
>
> --
>_  | Peter J. Holzer| Story must make more sense than reality.
> |_|_) ||
> | |   | h...@hjp.at |-- Charles Stross, "Creative writing
> __/   | http://www.hjp.at/ |   challenge!"
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to determine user's screensize?

[Igor Korot]

Hi,

On Sat, Oct 31, 2020, 11:40 AM Grant Edwards 
wrote:

> On 2020-10-31, Peter J. Holzer  wrote:
>
> > Very often this is not the case: An image viewer will be used to
> > display images which are larger than the screen.
>
> Tell the image widget what image you want to display, and then forget
> about it. Let the toolkit and window manager do their jobs.
>

You also should pick an appropriate control for displaying it.
I don't think you can use static window - you should be using something
with the scrollbar, which will size accordingly and display scrollers on
demand.


> > A MUA may have to display hundreds of mailboxes, and maybe tens of
> > thousands of mails in a single mailbox.
>
> No. It doesn't. It has to display a tree widget that shows N items and
> holds tens of thousands of items, or a scrolling list widget than
> shows M items and holds tens of thousands of items.  Pick reasonable
> initial default values for N,M and then let the window manager and
> user do the right thing.
>

Exactly.


> > 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.
>
> They do in a well-written application.
>

As I said earlier - that's why devs get their money.


> --
> Gran
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to determine user's screensize?

[Igor Korot]

Hi,

On Sat, Oct 31, 2020, 12:01 PM <2qdxy4rzwzuui...@potatochowder.com> wrote:

> On 2020-10-31 at 14:37:52 +0100,
> "Peter J. Holzer"  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.  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
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to determine user's screensize?

[Tim Chase]

On 2020-10-31 15:22, Grant Edwards wrote:
> > A MUA may have to display hundreds of mailboxes, and maybe tens of
> > thousands of mails in a single mailbox.  
> 
> No. It doesn't. It has to display a tree widget that shows N items
> and holds tens of thousands of items, or a scrolling list widget
> than shows M items and holds tens of thousands of items.  Pick
> reasonable initial default values for N,M and then let the window
> manager and user do the right thing.

But that's exactly the issue.  On my phone, a "reasonable default N"
might be 7 items and consume the whole screen; whereas on my netbook,
a "reasonable default N" might be 15 in one layout or 25 in another;
and on my daily driver, a "reasonable default N" might well be 50 or
100 depending on layout or monitor orientation.

How does the application determine "reasonable"?  It probes the
system for screen dimensions (hopefully with multi-monitor smarts)
and then makes an attempt to paint the display.

This doesn't free it from being subject to a window manager's
subsequent constraints, but at least allows the application to make
some sensible choices for initial defaults.  Some window-managers are
dumb (glares at Windows), some are accommodating (I like how Fluxbox
behaves), some are dictatorial (e.g. tiling window managers that give
far less wiggle-room for applications' dimensions), and some largely
ignore the user ("maximize" on MacOS annoys me to no end, maximizing
only enough to display all the content; when what I want is to obscure
everything else for single-app focus; requiring me to manually resize
the window with the mouse so it fills the screen).

-tkc




-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to determine user's screensize?

[Chris Angelico]

On Sun, Nov 1, 2020 at 4:10 AM Igor Korot  wrote:
>
> Hi,
>
> On Sat, Oct 31, 2020, 8:40 AM Peter J. Holzer  wrote:
>
> > On 2020-10-31 07:51:38 -0500, 2qdxy4rzwzuui...@potatochowder.com wrote:
> > > On 2020-10-31 at 13:02:03 +0100,
> > > "Peter J. Holzer"  wrote:
> > > > On 2020-10-31 12:30:43 +1100, Chris Angelico wrote:
> > > > > There is no valid way for an application to read my mind and size
> > > > > itself. Attempting to query my screen size seems to just make things
> > > > > worse in a lot of situations.
> > >
> > > > You still haven't answered the question: Where should the initial
> > > > window size come from? Does your window manager tell the application
> > > > how large a window should be? And if it does, can you as a user
> > > > configure that? I don't think mine (xfce) does that. (I guess tiling
> > > > WMs generally do that, but I've never used one.)
> > >
> > > 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 (or at least guaranteed to be
> > smaller than the screen size).
> >
>
> Any control at any given moment has a fixed size.

Yes - as determined by the layout manager, NOT the application.

> If I can't set the initial size of the control in the appropriate layout
> system, then this is not a layout system.

Sure, but the initial size should not be defined in pixels - it should
be defined by whatever makes logical sense ("a list box with room to
show these items").

> After the initial size is set it is up to the application to properly give
> the aspect ratio, font sizes, etc when the application is moved between the
> windows, resized, or DPI has changed, etc.

Why? Are you running on a potato where these kinds of basics aren't
handled by the window manager? Get a better window manager.

> > 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.
> >
> > (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.)
> >
>
> This is exactly my point.
> If the underlying toolkit is smart enough and the layout system is good
> then it won't matter.
>
>
> > 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.
> >
>
> Of course not.
> Thats why software devs are paid big money to do proper designs.
>

And that's why the companies that pay big money to get software devs
to do "proper designs" inevitably end up with pixel-precise rigid
layouts that are utterly unusable on any system the devs didn't test
on.

Meanwhile, people like me - and several others who've posted in this
thread - take the lower-effort option that gives better results. We
define our layouts by rules, and allow the system to define the flow.
Pages like this might be a bit ugly, but I've spent maybe half an hour
working on the layout:

https://sikorsky.rosuav.com/hypetrain?for=devicat

The mobile version took me FAR more effort. I might have put... an
entire hour into this. Maybe even 90 minutes.

https://sikorsky.rosuav.com/hypetrain?for=devicat&mobile=1

Try those on different sizes of screens. Try them on different font
sizes, DPI settings, or anything else you care about. They might not
be the fanciest, they might not be the most showy, but they're not
much more ugly on any other system than they are on my own.

I do the same with desktop layouts too, although it's harder to
showcase that. My Dungeons & Dragons character sheet manager is
entirely rule-based in its GUI, with everything defined as "put a box
here labelled Attributes, and inside it, label/input pairs for STR,
DEX, INT, WIS, CON, CHA". It is *far* easier to maintain than
something where you have to manually lay everything out in pixel
positions.

Why do people get paid big money to make suboptimal designs? Because
the people paying them want something that looks good, not something
that can actually be used by everyone. Because actual usability
testing is incredibly rare. Because it's really hard to put a graph of
how annoyed your customers get with your web site onto a PowerPoint
slide.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to determine user's screensize?

[Peter J. Holzer]

On 2020-10-31 11:58:41 -0500, 2qdxy4rzwzuui...@potatochowder.com wrote:
> On 2020-10-31 at 14:37:52 +0100,
> "Peter J. Holzer"  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 windo

Re: Best way to determine user's screensize?

[Ethan Furman]

On 10/31/20 11:24 AM, Peter J. Holzer wrote:

On 2020-10-31 11:58:41 -0500, 2qdxy4rzwzuui...@potatochowder.com wrote:



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.


I'm not sure which of the above two snippets I'm (dis)agreeing with, but if the user has specified in the config file 
that they want "full screen", how does the application tell the layout manager that?


(And yes, I have three screens, and each one has a full-size window running in it.  Also, four virtual desktops, one for 
each area of interest.  I hate overlapping windows.)


--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to determine user's screensize?

[Peter J. Holzer]

On 2020-10-31 11:54:59 -0500, Igor Korot wrote:
> On Sat, Oct 31, 2020, 8:40 AM Peter J. Holzer  wrote:
> 
> > On 2020-10-31 07:51:38 -0500, 2qdxy4rzwzuui...@potatochowder.com wrote:
> > > On 2020-10-31 at 13:02:03 +0100,
> > > "Peter J. Holzer"  wrote:
> > > > On 2020-10-31 12:30:43 +1100, Chris Angelico wrote:
> > > > > There is no valid way for an application to read my mind and size
> > > > > itself. Attempting to query my screen size seems to just make things
> > > > > worse in a lot of situations.
> > >
> > > > You still haven't answered the question: Where should the initial
> > > > window size come from? Does your window manager tell the application
> > > > how large a window should be? And if it does, can you as a user
> > > > configure that? I don't think mine (xfce) does that. (I guess tiling
> > > > WMs generally do that, but I've never used one.)
> > >
> > > 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 (or at least guaranteed to be
> > smaller than the screen size).
> >
> 
> Any control at any given moment has a fixed size.
> If I can't set the initial size of the control in the appropriate layout
> system, then this is not a layout system.

Correct. But you and Chris and others were arguing that this size should
never be based on the screen size. Instead suggestions included "a guess"
and "a reasonable N".


> > 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.
> >
> > 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.
> >
> 
> What is natural size? Please define this term.

Depends on the thing to be displayed of course.

For a JPG or PNG image, the "natural size" would be one image pixel =
one display pixel. Except that for small images on high dpi displays it
might be a "logical pixel" (is that the correct term?) instead.

For a a text, the natural size is a box around the complete text typeset
in the way it should be displayed.

Similarly for a list or a table.

A tree has two sizes that could be considered "natural": Fully collapsed
and fully expanded. But it will almost always be somewhere in between,
so that's another situation where a programmer would need to determine
what is reasonable.


> > 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.
> >
> > (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.)
> >
> 
> This is exactly my point.
> If the underlying toolkit is smart enough and the layout system is good
> then it won't matter.

Well. I haven't seen one which is smart enough. It might be because I
don't do desktop development (when I need a UI, I write a web app), but
I think the problem is (in general) unsolvable without domain knowledge,
and so far nobody has written anything to change my mind. I would need
to see either code or at least an explanation how this is done. "It just
works" is not a good argument for a techie.


> > 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.
> >
> 
> Of course not.
> Thats why software devs are paid big money to do proper designs. 😀

Well, I have to agree with Chris here. Most programmers (especially
those who are paid big bucks) don't do proper designs.

hp

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

Re: Best way to determine user's screensize?

[Peter J. Holzer]

On 2020-10-31 11:52:31 -0700, Ethan Furman wrote:
> On 10/31/20 11:24 AM, Peter J. Holzer wrote:
> > On 2020-10-31 11:58:41 -0500, 2qdxy4rzwzuui...@potatochowder.com wrote:
> > > 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.
> 
> I'm not sure which of the above two snippets I'm (dis)agreeing with, but if
> the user has specified in the config file that they want "full screen", how
> does the application tell the layout manager that?

It doesn't directly. It tells the window manager that it wants to go
full screen. The window manager resizes the window, which causes a
resize event to be sent to the application. The application then asks
the layout manager to recompute the layout based on the new window size
(the latter will probably be managed automatically by the framework, so
the programmer doesn't have to write code for that, but it's still part
of the application).

hp

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

Re: Best way to determine user's screensize?

[Random832]

On Sat, Oct 31, 2020, at 01:26, Igor Korot wrote:
> This one is for "JAVAsucks" -
> https://docs.oracle.com/javase/tutorial/uiswing/layout/visual.html
> This one is for wxWidgets - https://docs.wxwidgets.org/3.0/overview_sizer.html
> This one is for Qt - https://doc.qt.io/qt-5/layout.html
> This one is for GTK -
> https://developer.gnome.org/gtk3/stable/LayoutContainers.html
> 
> Are you still going to argue "it does not exist"?

Those have nothing to do with the sizing or placement of top-level windows, 
they are for placements of widgets within the top-level window.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why x+=1 doesn't return x value instead of an object

[dn via Python-list]

On 31/10/2020 19:41, Chris Angelico wrote:

On Sat, Oct 31, 2020 at 4:44 PM dn via Python-list
 wrote:

Free advice: whatever you do, don't call @Chris a walrus!


Yeah... I do have quite a moustache, but it doesn't merit a high title
like that! :)


It's the tusks I'd be worried about!
Is Dracula jealous of your bite?
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: GUI: I am also looking for a nudge into the best (GUI) direction.

[Barry Scott]

> On 31 Oct 2020, at 16:37, Igor Korot  wrote:
> 
> Hi, Barry,
> 
> On Sat, Oct 31, 2020, 3:39 AM Barry Scott  > wrote:
> 
> 
> > On 29 Oct 2020, at 15:54, flaskee via Python-list  > > wrote:
> > 
> > Hello!
> > 
> > I've been reading the GUI toolkit posts.
> > 
> > If anyone can give me a push in the right python direction on
> > my needs, I'd be grateful.
> > 
> > This is for business applications, not games.
> > (but if a game toolkit fits...)
> > 
> 
> I choose to use PyQt5 for my apps that run on Linux, macOS and Windows.
> 
> You can see my apps code if you wish to see working examples:
> 
> https://barrys-emacs.org  
> >
> https://scm-workbench.barrys-emacs.org/ 
>  
>  >
> 
> In the past I had used wxPython but it had too many problems and it was 
> cheaper for
> me to port in PyQt5 then have to carry a lot of platform specific workarounds.
> 
> PyQt5 can target iOS and android.
> 
> With PyQt5 I can develop on Linux and have high confidence that the code will 
> run the
> same way on macOS and Windows.
> 
> Qt does not use native controls on 3 major platforms and so is out of the 
> question...

It looks and feels native so I've been very happy with the way the Qt widgets 
work.

It does not appear to me that use native widgets is important for a tool kit.

So I think that Qt is worth considering.

Barry



> 
> Thank you.
> 
> 
> Barry
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list 
> 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to determine user's screensize?

[2QdxY4RzWzUUiLuE]

On 2020-10-31 at 19:24:34 +0100,
"Peter J. Holzer"  wrote:

> On 2020-10-31 11:58:41 -0500, 2qdxy4rzwzuui...@potatochowder.com wrote:
> > On 2020-10-31 at 14:37:52 +0100,
> > "Peter J. Holzer"  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 ...

Then we already have a terminology issue.  :-)

I'll take at least part of the blame because my question as written is
ambiguous:  what I meant to ask was whether or not the application can
specify a predetermined size, in pixels or in millimeters, for that
window.  I believe that the answer is no, because the "correct" size for
that window depends on other things, like the size of the font, the
density of the pixels, user preferences, etc., which can change over
time.  (And my argument remains that said correct size does *not* depend
on the size(s) or the aspect ratio(s) of the screen(s).)

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

Yep.

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

The application should pick a size for that widget in lines and columns
of *glyphs*, or a size that matches a potential physical rendering (like
a page in a book) in millimeters, again regardless of the
characteristics of the screen.  Yes, an initial guess may be suboptimal.
Ambitious users can adjust the window and/or their preferences to taste,
and have to recognize that such preferences may depend on other things.
When I switched from a 1920x1080 laptop display to a 3840x2160 laptop
display that was the same size, I had to change a lot of preferences
because applications and font libraries made incorrect assumptions about
pixel density.

I can almost see an application (or a developer) wanting to make that
editing widget, say, 80 characters wide and 2/3 as tall as the screen,
because vertical scroll bars are perfectly acceptable.  Yeah, that'll
look pretty.  Until I (the user) get that wall-size display but I still
want my editing widgets and the text therein to be the same size as my
handwritten notes on real A4 paper.

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

That's how video terminals used to be, 80x24, until they weren't.

That's how Apple Macinntosh's used to be, 512x384x1, until they weren't.

You get the idea.  :-)

In Apple's defense, the docs I used in 1984 laid out a completely
heterogeneous display environment, and had instructions for software
that would work when a given window spanned multiple physical display
devices.  I remember how impressed I was when my simple image viewer
worded as advertised when we got our first external color displays.

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

Some information, sure.  Please don't assume that physical p

Re: Best way to determine user's screensize?

[Peter J. Holzer]

On 2020-10-31 17:12:36 -0500, 2qdxy4rzwzuui...@potatochowder.com wrote:
> On 2020-10-31 at 19:24:34 +0100,
> "Peter J. Holzer"  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.

> > > 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.
> 
> Again, I don't think we're disagreeing.  Our shiny new MUA comes up and
> finds 10 million messages in the user's inbox.  Pick a number of
> messages, like 10, or 42, and start there.  Don't start with the screen
> size and do a bunch of font metric arithmetic to come up with a number
> of pixels.

We do disagree fundamentally here. I think picking an arbitrary number
like 10 or 42 out of thin air is fundamentally broken. Computing than
number by dividing the screen height (minus chrome) by the height of one
element is the right thing to do.

(Using the number stored last time when the user resized the window is
of course also ok (because that was the user, not the programmer). But
the application has to be ready to adjust that if the current screen is
smaller)

hp

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

Re: GUI: I am also looking for a nudge into the best (GUI) direction.

[Greg Ewing]

On 1/11/20 9:44 am, Barry Scott wrote:


It does not appear to me that use native widgets is important for a tool kit.


It's not strictly necessary. However, recreating the exact appearance
and behaviour of native widgets is a lot of work, and difficult to do
well -- most toolkits that attempt this don't manage to get all the
details exactly right.

Moreover, a lot of maintenance effort is needed to keep up with
changes to the native widgets which frequently happen with OS updates.
And even if the toolkit is kept up to date, you need to install a
new version of the toolkit when changes occur.

On the other hand, if the toolkit wraps the platform's native widgets,
it gets all the correct appearance and behaviour, and automatically
tracks changes.

For these reasons I regard "uses native widgets" as a mark of quality
for a toolkit.

--
Greg

--
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to determine user's screensize?

[Serhiy Storchaka]

30.10.20 17:56, flaskee via Python-list пише:
> Perhaps a more tactical approach would best to figure
> out how to do cross-platform python apps.
> 
> What is the best approach to determining the user's available screensize,
> when they open your python application?
> 
> Note that the "desktop" application could be running on Android, iOS,
> MacOS, Windows or Linux (I think that I understand how to handle it for 
> browser-based things.)
> 
> As close to an all Python answer as possible, would be optimal.

It depends on the GUI toolkit you are using.

For example in Tkinter you can use methods winfo_screenwidth() and
winfo_screenheight() of your widget if you need the size in pixels.
winfo_screenmmwidth() and winfo_screenmmheight() return the size in
millimeters.

For other toolkits look at the corresponding documentation.

-- 
https://mail.python.org/mailman/listinfo/python-list

Find word by given characters

[Bischoop]

I'm working on a script i which user inputs letters and then a printed
words containing those letters. The scripts works however I can't solve
one problem , it prints also words in which these letters occur more 
than once.
---
Fore example:
Letters: at
Output: auto, autobahn.
---

I supposed to not print word: "autobahn" because I've given it only one
letter "a".

Here is a link to the code:
https://bpa.st/UTAA

Thanks in advance 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Find word by given characters

[MRAB]

On 2020-11-01 00:36, Bischoop wrote:

I'm working on a script i which user inputs letters and then a printed
words containing those letters. The scripts works however I can't solve
one problem , it prints also words in which these letters occur more
than once.
---
Fore example:
Letters: at
Output: auto, autobahn.
---

I supposed to not print word: "autobahn" because I've given it only one
letter "a".

Here is a link to the code:
https://bpa.st/UTAA

Thanks in advance


This is what's happening in the inner loop:

Iteration 1: word contains 1 of 'a', letters contains 2 of 'a', so don't 
print the word.


Iteration 2: word contains 1 of 't', letters contains 1 of 't', so print 
the word.

--
https://mail.python.org/mailman/listinfo/python-list

Re: Find word by given characters

[Terry Reedy]

On 10/31/2020 8:36 PM, Bischoop wrote:

I'm working on a script i which user inputs letters and then a printed
words containing those letters. The scripts works however I can't solve
one problem , it prints also words in which these letters occur more
than once.
---
Fore example:
Letters: at
Output: auto, autobahn.
---

I supposed to not print word: "autobahn" because I've given it only one
letter "a".


If you use collections.counter on both the letters and the word, you 
could check that the counts in letters are matched by the counts for 
word.  Make sure to use 'and' between count matches.



--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Best way to determine user's screensize?

[Dan Stromberg]

On Sat, Oct 31, 2020 at 4:18 PM Peter J. Holzer  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"  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

Re: GUI: I am also looking for a nudge into the best (GUI) direction.

[Michael Torrie]

On 10/31/20 5:42 PM, Greg Ewing wrote:
> On 1/11/20 9:44 am, Barry Scott wrote:
> 
>> It does not appear to me that use native widgets is important for a tool kit.
> 
> It's not strictly necessary. However, recreating the exact appearance
> and behaviour of native widgets is a lot of work, and difficult to do
> well -- most toolkits that attempt this don't manage to get all the
> details exactly right.
> 
> Moreover, a lot of maintenance effort is needed to keep up with
> changes to the native widgets which frequently happen with OS updates.
> And even if the toolkit is kept up to date, you need to install a
> new version of the toolkit when changes occur.

Maybe. However it seems like this is the route nearly everyone takes
these days, include MS themselves. See below.

> On the other hand, if the toolkit wraps the platform's native widgets,
> it gets all the correct appearance and behaviour, and automatically
> tracks changes.
> 
> For these reasons I regard "uses native widgets" as a mark of quality
> for a toolkit.

In C# world, WinForms is often used, but it's not "native" win32
widgets.  Widgets are implemented in managed code (according to
Wikipedia) that draw themselves using the theming dll so they look
native, or at least look somewhat consistent with regards to button
styles, fonts, colors, etc.

With the introduction of UWP apps, "native" has further lost meaning.
Going forward, perhaps MS intends UWP to be the new native. I don't know
and I'm not sure MS knows.

MS Office hasn't used native win32 widgets for many years now (since
Office 2000 I think, perhaps before).  In fact I know of very few
Windows applications that use exclusively the basic native widget set
from win32.  Nearly all apps use some kind of GUI framework, from MS or
elsewhere, that implement their own widgets, often using the Theming
system to draw them and get the colors right.  Some apps don't even
bother trying to look native--and yes those tend to be low-quality apps
like antivirus programs.  Shudder.

I think notepad.exe, regedit.exe, etc, are probably the only apps I've
used recently that actually use "native" win32 widgets.
-- 
https://mail.python.org/mailman/listinfo/python-list