Tiny widgets on high resolution display

[GigiG]

Hi all,
is there a way to scale all widgets and text in tk? I recently start using an Alienware R5 laptop (3840x2160 display resolution) in Linux and all widgets are really tiny ...
Thanks
Regards

[Harald Oehlmann]

Look to tk scale command.
For icons, awthemes may be helpful.

[GigiG]

Hi tried with several values using `tk scaling n.n` but nothing change

[Harald Oehlmann]

AFAIK you have to set it before creating toplevels, widgets...

[nemethi]

Am 14.10.20 um 17:21 schrieb GigiG:

If you download my Tablelist 6.10 or Scrollutil 1.6 package then any one
of the lines

package require tablelist
package require tablelist_tile
package require scrollutil
package require scrollutil_tile

will trigger a scaling-related initialization code that:

- sets the variable tablelist::scalingpct or scrollutil::scalingpct to
one of the values 100, 125, 150, 175, and 200, corresponding to the
display's DPI scaling level;

- passes the scaling factor corresponding to the scaling percentage to
the "tk scaling" command;

- corrects the sizes of the standard fonts (by replacing the sizes in
pixels with sizes in points);

- scales the scrollbar, ttk::scrollbar, ttk::combobox, ttk::spinbox,
ttk::menubutton, ttk::checkbutton, and ttk::radiobutton widgets.

See the section "More on tablelist::scalingpct" or "More on
scrollutil::scalingpct" in Tablelist Programmer's Guide or Scrollutil
Programmer's Guide for details.

To make sure that your application will be scaling-aware, you should use
screen distances and font sizes in points rather than pixels wherever
possible, and images whose sizes correspond to the scaling percentage.

Out of curiosity: Which desktop environment are you using on your Linux
laptop? The initialization code described above supports XFCE, MATE,
GNOME on Xorg or Wayland, Budgie, Cinnamon, and KDE Plasma on Xorg or
Wayland.

--
Csaba Nemethi https://www.nemethi.de mailto:csaba....@t-online.de

[Harald Oehlmann]

Thank you, Csaba. I was hoping a wizard will step in.
Thanks, Harald

[GigiG]

Thanks Csaba, I`ll try your package soon. In the meantime I`m working with simple `option add` like this:
if {[winfo screenwidth .] > 3000} { # Alienware R5 high resolution display ...
set fnt "tahoma 18"
option add *Label.Font $fnt
option add *Scale.width 30
option add *Checkbutton.indicatorOn 0
option add *Checkbutton.width 5
option add *Menubutton.Font $fnt
option add *Menu.Font $fnt
}
I`m on Linux Mint 20 MATE 1.24 X.Org X server 1.0.16 (I`ll check with NVidia 450.80 driver also, the GPU is a GeForce GTX 1080M)
Regards

[Paul Taylor]

I posted what's below to a similar thread a couple of years ago, this is what worked for me:


I recently updated one of my apps so I could use it on a new laptop I bought with a high DPI screen. The app has a fairly simple GUI, but to get it to be usable I did two things:

(1) Provide a font size menu button in a settings dialog, and then I could change the font size to be just right (and also used points instead of pixels for size, so that it's more right to start with).

Once I got the font size from the settings dialog, I then changed the fonts using the following code:

foreach f [font names] {
font configure $f -size $size
}

where I found a size of between 8 to 12 gives a more than adequate range.

(2) Change all the locations where I'd used pixel sizes to point sizes for a nice widget layout, so for example from this

grid $someWidget -padx 10 -pady 10

to this

grid $someWidget -padx 7pt -pady 7pt

I still need to do something about my toolbar icons, but the rest of my app now is fine, and the toolbar icons are not that bad. What I'll do there is probably just have two sizes of icons and use the ones most appropriate based on the DPI reported by Tk.

[Harald Oehlmann]

Paul,
great, that is a very similar approach I use. You may see it at my last
two AndroWish talks at ETCL.
About the toolbar:
I measure the size of the characters after scaled and use svg images
with parameter -scaletoheight set to the character size. So, they are
the same size.

Harald

[Alexandru]

At least on Windows the OS is taking care of the scaling of various apps. The only thing in Tcl/Tk that not compatible with the OS scaling are the images. To solve this issue I replaced all my png icons though SVG icons. Then I have a procedure that creates images from the SVGs considering the current scaling. I'm using for this the tksvg package. All the SVGs are scaled using a global variable

variable ui_scaling [expr {[tk scaling] * 0.75}]

This works perfect for me an I get pixel free UI accoring the the global setup of the Windows scaling.

In addition I have to take care of all the situations where Tk commands expect arguments in pixel units. Instead of writing fixed pixel values I write e.g. [UIScaleInteger 300] instead of simplty 300 (pixel). The procedure UIScaleInteger is defined like this:

variable ui_scaling [expr {[tk scaling] * 0.75}]

proc UIScaleInteger {value} {
variable ui_scaling
if {![info exists ui_scaling]} {
return 1
}
return [expr {int($value*$ui_scaling)}]
}

[Alexandru]

BTW: There is one thing that does not work with scaling: ttk::checkbutton but I can live with that for the moment.

[Harald Oehlmann]

Am 15.10.2020 um 20:44 schrieb Alexandru:
>
> BTW: There is one thing that does not work with scaling: ttk::checkbutton but I can live with that for the moment.
>

Use AWThemes ;-)

[Rich]

Alexandru <alexandr...@meshparts.de> wrote:
> In addition I have to take care of all the situations where Tk
> commands expect arguments in pixel units. Instead of writing fixed
> pixel values I write e.g. [UIScaleInteger 300] instead of simplty
> 300 (pixel). The procedure UIScaleInteger is defined like this:

Almost all Tk commands that take distances also consume a modifier "c",
"i", "m" for physical measured values c=cm, i=inch, m=mm.

What do you get if you specify Tk distances using these units (and
letting Tk convert from mm, cm, or inch to an appropriate number of
pixels internally) instead of raw pixel values and your custom scaling
proc?

[Alexandru]

I don't see how cm or mm units can work in an scalable UI. Specifying pixels works better for me, because I can always refer to a full HD resolution. On other screen the user takes care about global scaling applications.

[Alexandru]

What if I want to let the Windows specific theme as it is. How can I use AWThemes to make checkbuttons scalable but don't change their look?

[Brad Lanam]

On Sunday, October 18, 2020 at 2:46:04 AM UTC-7, Alexandru wrote:
> I don't see how cm or mm units can work in an scalable UI. Specifying pixels works better for me, because I can always refer to a full HD resolution. On other screen the user takes care about global scaling applications.

I use 'points', but it's the same idea. If [tk scaling] is set correctly,
and if the computer has the correct size of the screen set, points/cm/mm works.

10 pixels is a different height for different resolutions. 10 points is always
10 points if [tk scaling] and the screen size are set correctly (or cm/mm).

[Brad Lanam]

Someone would need to write a theme that looks just like the windows theme.

You could try: ttk::style configure TCheckbutton -indicatordiameter size
and see if it works with the vista theme.

[Rich]

Because if the tk scaling factor, and if the OS screen driver properly
knows the resolution of the monitor, then when you ask for, say, 1i
(1 inch, just to make the math easy) then:

1) on a 72 dpi screen you get 72 pixels of space

2) on a 100 dpi screen you get 100 pixels of space

and

3) on a 300 dpi screen you get 300 pixels of space

I.e., you ask for a specific size (1mm, 0.15inch, 4cm) and the system
performs the necessary scaling math, based on what is attached, to
determine how many pixels to light up.

This also makes your UI usable for more users with varying different
harddware setups, those with 72dpi screens see 1mm of space, those with
100dpi screens see 1mm of space, and those with 300dpi screens see 1mm
of space (i.e., the space they see is constant, even though the number
of pixels required for their particular hardware changes).

That is the magic of using measurement units instead of pixels, you no
longer need worry about what hardware the user has, your UI code
remains the same, and appears (or should, provided the OS screen driver
works properly) identical to all.

This is the "resoultion independence" concept that has been known since
at least 1978 when Knuth introduced the concept in Tex.

https://en.wikipedia.org/wiki/Resolution_independence

[Alexandru]

Maybe I'm missing something, but in general, I never want a button to have a specific absolute size (in length units). I want it to have a relative size based on the size of the screen. So that my UI looks the same on any screen of same scaling.

If I specify a button of size 1cm and the screen is 100cm wide, that's fine. But if the screen is only 5cm wide, then I have a problem.

[Rich]

Ah, you are going for a different angle. You don't want the UI to look
the same size on various screens of various pixel densities, you want
the UI to grow/shrink as the absolute size of the screen grows/shrinks.

The measurement values (inch, mm, etc.) provide for a UI that looks the
same size on a 72dpi screen as it does on a 300dpi screen (provided the
OS rendering reports proper pixel density values). In your case, you
will always have to do some adjustments yourself of the requested sizes
of UI elements to keep them in the same ratio to physical screen width.

You can do that either with pixels, or with measurements, but you'd
still have to do the adjustments yourself.

[Brad Lanam]

The idea is that your UI is say, 20cm wide, has 1cm high buttons.
Now whether you use a 72dpi/30cm screen or a 144dpi/15cm screen or
72dpi/100cm screen or a 300dpi/200cm screen (gah, I'm mixing units),
your UI will still be 20cm wide, the buttons will always be usable
at 1cm high, no matter which screen they're on. The fonts are always
the same size and are readable.

Now, you are suggesting a use case where the UI elements scale depending
on the screen size. That's something different, and you'll have to
implement that yourself.

[Christian Gollwitzer]

Am 18.10.20 um 23:24 schrieb Alexandru:

Both understandings of "scalability" have their appeal, but also their
limits. In the first approach - buttons have a fixed physical size - the
App appears sharper on a higher resolution screen (DPI) and with more
space to work on a physically bigger screen. This is how many Office
apps work. Consider MS Word - on a bigger screen you get a larger area
where you can type. It's not that the buttons become bigger. However,
e.g. when you want to demonstrate MS Word to a crowd using a projector
or big TV with 5 m in size, you want the buttons scaling up.

Now imagine that you really shrink the UI to 5cm in width, i.e. to a
mobile phone. MS Word is unusable for both these scalings, if you keep
the buttons at fixed size, not all buttons fit on the screen and there
is no space left to type. If you scale it down, it fits all there, but
is too small to read or hit the buttons. So, argueing with a 5cm screen
is obviously flawed. You need a different design for mobile than for a
big screen.

In aRTist - so before real hiDPI and before mobile, and before tksvg -
we simply had three sizes for all of the icons, and the user could
switch between small, middle and large buttons. That is still the best
compromise, I think.

Christian

[Alexandru]

Christian Gollwitzer schrieb am Montag, 19. Oktober 2020 um 08:52:13 UTC+2:
> Am 18.10.20 um 23:24 schrieb Alexandru:
> > Rich schrieb am Sonntag, 18. Oktober 2020 um 17:12:33 UTC+2:
> >>
> >> https://en.wikipedia.org/wiki/Resolution_independence
> >
> > Maybe I'm missing something, but in general, I never want a button to have a specific absolute size (in length units). I want it to have a relative size based on the size of the screen. So that my UI looks the same on any screen of same scaling.
> >
> > If I specify a button of size 1cm and the screen is 100cm wide, that's fine. But if the screen is only 5cm wide, then I have a problem.
> >
> Both understandings of "scalability" have their appeal, but also their
> limits. In the first approach - buttons have a fixed physical size - the
> App appears sharper on a higher resolution screen (DPI) and with more
> space to work on a physically bigger screen. This is how many Office
> apps work. Consider MS Word - on a bigger screen you get a larger area
> where you can type. It's not that the buttons become bigger. However,
> e.g. when you want to demonstrate MS Word to a crowd using a projector
> or big TV with 5 m in size, you want the buttons scaling up.

Exactly, an for this purpose there is this Windows setting which sets the scaling of all apps. This way I can make buttons larger, no need to do this in Tcl/Tk.
Also I must specify that I'm not designing for small hand held devices such as smar phones. I target normal desktop monitors. This reduces the requirements and that's why the problem can be solved realtively easily as described in my original post.

>
> Now imagine that you really shrink the UI to 5cm in width, i.e. to a
> mobile phone. MS Word is unusable for both these scalings, if you keep
> the buttons at fixed size, not all buttons fit on the screen and there
> is no space left to type. If you scale it down, it fits all there, but
> is too small to read or hit the buttons. So, argueing with a 5cm screen
> is obviously flawed. You need a different design for mobile than for a
> big screen.
>
> In aRTist - so before real hiDPI and before mobile, and before tksvg -
> we simply had three sizes for all of the icons, and the user could
> switch between small, middle and large buttons. That is still the best
> compromise, I think.
>
> Christian

We can see how this issue in solved in HTML5 by using the raster (columns and rows) model and how the model is fluid. In addition in CSS the styles can be different for different devices. But I think this is completly different question/issue regarding conventional UI languages, which could or not catch up with the new concepts in the Web world. I wished there was something similar for Tcl/Tk, a new kind of geometry manager, a fluid one.

[Brad Lanam]

On Monday, October 19, 2020 at 6:45:13 AM UTC-7, Alexandru wrote:
> We can see how this issue in solved in HTML5 by using the raster (columns and rows) model and how the model is fluid. In addition in CSS the styles can be different for different devices. But I think this is completly different question/issue regarding conventional UI languages, which could or not catch up with the new concepts in the Web world. I wished there was something similar for Tcl/Tk, a new kind of geometry manager, a fluid one.

I think grid/pack is still easier to use than HTML Flex. But yes, it
would be nice to have a fluid option to allow widgets to roll over on to
the next row rather than shrinking or disappearing.

[nemethi]

Am 18.10.20 um 23:24 schrieb Alexandru:

> Maybe I'm missing something, but in general, I never want a button to have a specific absolute size (in length units). I want it to have a relative size based on the size of the screen. So that my UI looks the same on any screen of same scaling.
>
> If I specify a button of size 1cm and the screen is 100cm wide, that's fine. But if the screen is only 5cm wide, then I have a problem.
>

I am jumping in because of a misunderstanding that IMHO should be
clarified. It is related to the meaning of a screen distance specified
in points/inches/centimeters/millimeters rather than in pixels. To make
things easier to understand, I will refer to two monitors I have:

- a 24" display with full HD resolution (actually, 1920 x 1200, but in
the following I will refer to the width only), which is connected to my PC;

- a 14" notebook display with full HD resolution (1920 x 1080).

Let's run the following test script on both computers:

pack [frame .f -background red -width 5c -height 4c]

If you take a ruler and measure the width of the frame, on the 24"
display you get *about 5 cm*. This is the expected result *because this
display has the traditional resolution density of 96 pixels/inch* and
needs no scaling, being large enough even for my old eyes. Note that 5
cm are about one tenth of the display's usable width (which is approx.
51 cm).

OTOH, the frame displayed by the same script on the 14" notebook display
has a width of only *about 3 cm* if the DPI scaling factor is 100 %. It
gets wider (3.75 cm if the DPI scaling is set to 125 %, 4.5 cm if the
DPI scaling is 150 %, and so on). Again, note that 3 cm are about one
tenth of the display's usable width (which is approx. 31 cm).

From the above it follows that:

- *Specifying a screen distance in points/inches/centimeters/millimeters
is in most cases not equivalent to specifying an absolute size.* This
is only the case if the display has the reference resolution density of
96 pixels/inch and is not scaled.

- *If you specify screen distances in
points/inches/centimeters/millimeters rather than in pixels then your UI
will look "the same on any screen of same scaling" and resolution*.
This is much simpler and by far more efficient than using constructs
like [UIScaleInteger 300].

[Brad Lanam]

No, that does not follow.

You need to set your [tk scaling] correctly such that at least one monitor
will have the correct [tk scaling]. In which case the absolute units will
work correctly for one monitor. Not "about", yes "equivalent".

pack [frame .f -background red -width 5.1c -height 5.1c]

Adjust your [tk scaling] until the box above measures exactly 5.1c (2 inches).
(Be careful not to damage your screen when measuring).
You can add this to your .wishrc or add it to your applications you use.

Tk does not have separate [tk scaling] parameters
for different monitors. This is a limitation/bug in Tk.

[nemethi]

Am 21.10.20 um 17:21 schrieb Brad Lanam:

The two displays mentioned above belong to different computers.

You seem to state that a Tk application will only work correctly after
adjusting the [tk scaling]. If this were true then it would be
impossible to develop Tk applications that "just work". Who and how
should set the [tk scaling] for the end user's display(s)?

[Brad Lanam]

No, I don't state that they will only work correctly after adjusting
[tk scaling]. I state that setting [tk scaling] properly will allow the
absolute measurements to work correctly. [tk scaling] is set to a reasonable
default in the beginning.

As far as I know, the end user must set [tk scaling]. I know that Tk
has much of the information from the display management system to possibly
calculate [tk scaling] correctly. I don't know why it doesn't do this
when it can. Tk does not know about the windows scaling factor, but this
could be retrieved also.

I include a little utility in my application that displays a 2 inch box with
instructions so that a user can set [tk scaling] properly. In my setup
instructions, I include this step as part of the initial setup.

There are a couple scripts on the wiki page to help set [tk scaling].
https://wiki.tcl-lang.org/page/tk+scaling
One is a rather old version of mine.

[undro...@gmail.com]

How gets [tk scaling] its initial (bogus?) information (on X11)?
It reads out the data of screen resolution and pixels per millimeter (sic!)
from the xlib Display structure of the very first main window toplevel ".".
Later on, it is able to open many toplevels on theoretically hundreds of
other displays even on remote machines. With some love for Tk it seems not
impossible to increase these some hundred to 10k, provided that the new Tcl
kqueue/epoll notifier is part of the story and Xlib supports this, too.
But now due to [tk scaling] being bound to the display where the app was
born, we are tied to the initial display connection's screen information
(which can be overriden by a new scaling factor). And we apply this
(overridable) birth factor to all our many displays. A design decision,
which can't be easily overcome without breaking many eggs, displays, and
windows.

[nemethi]

Am 21.10.20 um 18:08 schrieb Brad Lanam:

In my original posting I just wanted to make clear that a frame created
with "-width 5c" will appear about 5 cm wide on the large 24" monitor
and only about 3 cm wide on the small 14" notebook display. The
emphasis was not on the *accurate* size but on the fact that using a
unit other than pixel is in most cases not the same as setting an
absolute size.

You are right that it is possible to adjust the [tk scaling] in such a
way that absolute measurements will work correctly. The two scripts on
the wiki are really interesting and valuable. OTOH, I don't think that
the end user really *must* set [tk scaling]. The vast majority of
applications don't need this setup step.

[Rich]

The reference to

"if the DPI scaling factor is 100 %. It gets wider
(3.75 cm if the DPI scaling is set to 125 %, 4.5 cm if the DPI scaling
is 150 %"

also implies Windows 10 and the preset choices of scaling factors
present in the Windows 10 equivalent of the control panel. If my
supposition is correct (these are Windows 10 systems) then what MS did
for W10 was cheat by lying to applications about the actual DPI
resolution of the physical screen in order to build those "100%, 125%,
and 150%" selections. If Tk on W10 is assuming the reported DPI value
of the screen from the OS is accurate (and I assume Tk believes the OS
to accurately report the screen resolution), and the OS is lying about
the screens DPI value, then the result will be exactly what you found,
a "measurement" value in Tk will not produce that same measurement on
the physical screen (and it should, asking for 1inch should give 1inch
on screen if nothing in the OS is lying about the screen resolution).

The fact that 100% is off implies that W10 may also be lying about the
physical screen resolution even when you tell it to use 100% (under the
assumption this was a W10 system, given the size factors presented).

[nemethi]

Am 21.10.20 um 23:41 schrieb Rich:

As already mentioned, the goal of my original posting was to clarify the
misunderstanding that specifying a width of 5c will (or at least should)
result in a physical width of 5 cm on all screens of the same resolution
(e.g. full HD). Your above lines confirm that this myth is quite
widespread.

On my 14" notebook I have not only Windows 10 but also three different
Linux distributions. On Windows, if the DPI scaling is set to 100 %
then [tk scaling] will be 1.333.... You stated that this is because
"W10 may also be lying about the physical screen resolution". Please
note that I get the same [tk scaling] value on Linux, too.
Consequently, not only Windows, but also Linux (more precisely, X11) is
"lying about the physical screen resolution". Indeed, [winfo
screenmmwidth .] is 508 both on my 24" display and on the 14" notebook
screen, *not only on Windows, but also on Linux*. This value, together
with [winfo screenwidth .], which is 1920 on both displays, regardless
of the windowing system, explains why we get the same initial [tk
scaling] value of 1.333... on both Windows and Linux.

As indicated by Brad, one can make sure that a width of 5c will result
in a physical width of 5 cm by setting [tk scaling] to a value which can
be determined with the aid of an appropriate Tcl script and a ruler.
While this is possible (and works as expected), I don't think that it
could be the general solution to the problem that apparently both
Windows and Linux are "lying about the physical screen resolution". I
personally have never encountered a software whose setup includes
instructions regarding a ruler that the user has to use to make some
measurements on his screen. And which must be repeated when changing
the display or the DPI scaling percentage. See also the posting by
Christian Werner in this thread for further arguments in favor of my
skepticism.

It appears much more realistic to me to accept the fact that the initial
values of [tk scaling] and [winfo screenmmwidth .] are based on a
*reference screen* having a resolution density of 96 pixels/inch. There
is nothing new regarding this -- see
https://www.w3.org/TR/css-values-3/#reference-pixel for a similar topic
in CSS. If one takes into account that (1) the values reported by both
Windows and X11 are based on a reference screen of the given resolution
(e.g., full HD) and (2) the viewing distance in case of a 14" screen is
much shorter than the one when looking at a 24" display, then it appears
normal that the physical sizes of the GUI components created using units
other than pixel are smaller on a 14" screen than on a 24" display.

[Brad Lanam]

On Thursday, October 22, 2020 at 6:52:18 AM UTC-7, nemethi wrote:
> As already mentioned, the goal of my original posting was to clarify the
> misunderstanding that specifying a width of 5c will (or at least should)
> result in a physical width of 5 cm on all screens of the same resolution
> (e.g. full HD). Your above lines confirm that this myth is quite
> widespread.

It's not a myth.
It's simply a fact that tk scaling is not set properly.
I fail to see the purpose of trying to turn a mis-configuration situation
(and buggy Tk core code) into a "myth".

a) Very often the monitors in X11 are not configured and X11 does not know
what width/height the monitor is.
So Tk defaults to some sane dpi/screen size.
This is the norm.
You can check your xrandr output to see what values are
currently set (or not).
b) Tk is currently broken. It seems to be unable to retrieve the correct
width/height settings in mm even when they are properly configured in X11.
I don't know how long this has been broken, but it's not working at all.

I am not familiar with the Windows code. No idea what it does about
determining the screen width/height in mm.

[Brad Lanam]

Actually it seems that Tk does not try to set 'tk scaling' properly.
When set properly, 'winfo screenmmwidth/height' return the correct values.

[Rich]

nemethi <csaba....@t-online.de> wrote:
> Am 21.10.20 um 23:41 schrieb Rich:

>> The reference to
>>
>> "if the DPI scaling factor is 100 %. It gets wider
>> (3.75 cm if the DPI scaling is set to 125 %, 4.5 cm if the DPI scaling
>> is 150 %"
>>
>> also implies Windows 10 and the preset choices of scaling factors
>> present in the Windows 10 equivalent of the control panel. If my
>> supposition is correct (these are Windows 10 systems) then what MS did
>> for W10 was cheat by lying to applications about the actual DPI
>> resolution of the physical screen in order to build those "100%, 125%,
>> and 150%" selections. If Tk on W10 is assuming the reported DPI value
>> of the screen from the OS is accurate (and I assume Tk believes the OS
>> to accurately report the screen resolution), and the OS is lying about
>> the screens DPI value, then the result will be exactly what you found,
>> a "measurement" value in Tk will not produce that same measurement on
>> the physical screen (and it should, asking for 1inch should give 1inch
>> on screen if nothing in the OS is lying about the screen resolution).
>>
>> The fact that 100% is off implies that W10 may also be lying about the
>> physical screen resolution even when you tell it to use 100% (under the
>> assumption this was a W10 system, given the size factors presented).
>>
>
> As already mentioned, the goal of my original posting was to clarify the
> misunderstanding that specifying a width of 5c will (or at least should)
> result in a physical width of 5 cm on all screens of the same resolution
> (e.g. full HD). Your above lines confirm that this myth is quite
> widespread.

Well, if I tell a system to produce a 5cm line, and it produces
something other than 5cm +- whatever minimum resolution it is capable
of producing, then it has not correctly honored my request. The fact
that many systems may be failing to honor the request to the limits of
their accuracy does not make their behavior correct, just common.
Requesting 5cm should, provided no bugs or miss-configurations, result
in 5cm.

> On my 14" notebook I have not only Windows 10 but also three different
> Linux distributions. On Windows, if the DPI scaling is set to 100 %
> then [tk scaling] will be 1.333.... You stated that this is because
> "W10 may also be lying about the physical screen resolution". Please
> note that I get the same [tk scaling] value on Linux, too.
> Consequently, not only Windows, but also Linux (more precisely, X11) is
> "lying about the physical screen resolution". Indeed, [winfo
> screenmmwidth .] is 508 both on my 24" display and on the 14" notebook
> screen, *not only on Windows, but also on Linux*. This value, together
> with [winfo screenwidth .], which is 1920 on both displays, regardless
> of the windowing system, explains why we get the same initial [tk
> scaling] value of 1.333... on both Windows and Linux.

I've subsequently found this
https://bugs.freedesktop.org/show_bug.cgi?id=23705 which while somewhat
rambling, seems to indicate that at some point, X11 was modified to
assume 96dpi /unless/ the user provides a DisplaySize parameter in
one's xorg.conf file, and to ignore the EDID resoluton values reported
from monitors. It also implies that ignoring the EDID was intentional
because, according to a few comments inside, manufactures often provide
incorrect EDID values, resulting in bogus DPI computations. So, yes,
it does appear that later X releases have begun /lying/ about the
screen's DPI value, unless the owner knows that they need to tell X
their screens physical size in the xorg.conf file.

I got the result of 1c == 1c on my screen because as it happens, it is
just shy of the default 96dpi that X chooses (actual DPI is a few
hundredths less than 94dpi). So I got 1c == 1c with Brad's example.

I then used xrandr to adjust my dpi settings and tested again. First,
I told X to use a dpi of 96*2 (192 dpi). Running the test, I got a 1c
wide box, and these tk scaling factors:
a: 2.6687680588389804
b: 4.003152088258471

Then, I told X the screen dpi was 96/2 (48 dpi). Running the test I
got a 0.5c wide box, and these tk scaling factors:
a: 0.6667979261009384
b: 4.003152088258471

So, for at least X11 (I don't have windows installed anywhere to test
with), if the dpi of the monitor is set properly, Tk computes a correct
scaling factor to give a real 5cm line when asking for a 5cm line.

However, it also seems that for any monitor resolution other than
96dpi, unless the owner knows to give X11 a DisplaySize parameter, the
result will be X11 returning the incorrect resolution value to apps
(yes, it is lying about the actual resolution).

> As indicated by Brad, one can make sure that a width of 5c will
> result in a physical width of 5 cm by setting [tk scaling] to a value
> which can be determined with the aid of an appropriate Tcl script and
> a ruler. While this is possible (and works as expected), I don't
> think that it could be the general solution to the problem that
> apparently both Windows and Linux are "lying about the physical
> screen resolution".

Agreed, with both of them reporting incorrect DPI values, there is no
guarantee that asking for 5c will return anything close to 5cm, except
in those situations where the Tk app is running on a monitor that
happens to also be 96dpi (or close thereto) or a user has configured
their system to report the true screen DPI resolution.

> It appears much more realistic to me to accept the fact that the
> initial values of [tk scaling] and [winfo screenmmwidth .] are based
> on a *reference screen* having a resolution density of 96
> pixels/inch.

This seems to be the case, but it seems that the "based upon a
reference screen" aspect is at the X11 and/or Windows OS level, not
within Tk. Tk appears to be correctly computing a scaling factor that
/would/ work in all cases if the OS reported the screen DPI accurately
as opposed to reporting the /reference dpi/ value. So in those rare
instances where a user configures their OS to report the real monitor
DPI value, Tk will compute a correct scale factor to produce real world
measurements from its m, c, and i values. But I suspect that the
instances of a screen with a resolution other than 96dpi being
correctly configured to report its true resolution by the owner are few
in number.

So the takeaway here is if one is creating a Tk app. that needs to
display correct measurement values on screen, one will have to also
walk a user through tweaking their tk scaling factor to be certain to
produce correct display sizes.

I also expect that if you calculate the resolution of your laptop
screen, and tell X11 the real world resolution (xrandr --dpi #) that
Brad's example will give you a 1cm sized red box on the laptop.

[Rich]

My tests that I just did and posted in another post about an hour ago
where I adjusted X11's screen resolution value (xrandr --dpi #) showed
that if the resolution is set correctly for the physical screen, then
Tk will set the tk scaling factor properly to produce correct
real-world measurement values.

So it looks like Tk might use the dpi value it is given by the OS
(Windows/X11/MacOs) and if that value is correct, then Tk's measurement
units will be correct.

But I also uncovered an X11 bug report that implied that X11 was
modified at some point to report 96dpi as screen resolution unless the
user goes out of their way to explicitly configure a display size via
xorg.conf. So if X11 tells Tk 96dpi, then Tk will calculate a tk
scaling appropriate for 96dpi, and if that happens to match the actual
physical screen, things work. But if 96dpi is not correct for the
physical screen, things are the wrong size.

[Brad Lanam]

On Thursday, October 22, 2020 at 7:18:25 PM UTC-7, Rich wrote:

I was rather surprised that defining the correct monitor size in xorg.conf
does not set the dpi (I thought it used to). But:

# correct
bll-g7:bll$ xrandr | grep mm
eDP-1-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 344mm x 194mm

# incorrect
bll-g7:bll$ xdpyinfo | grep -B2 resolution
screen #0:
dimensions: 1920x1080 pixels (508x286 millimeters)
resolution: 96x96 dots per inch

And that points back to the same bug you found (active since 2009).

I guess the xrandr --dpi method must be used to set the system-wide dpi.

[nemethi]

Am 23.10.20 um 02:11 schrieb Brad Lanam:

You call the way Tk currently computes [tk scaling] and [winfo
screenmmwidth .] "broken". You have correctly pointed out that their
are ways to work around this issue. You seem, however, to ignore a few
facts:

1. IMHO it is not user-friendly to request from the end user to make
some measurements with the aid of a ruler in order to make sure that [tk
scaling] will be correct. And that he or she has to repeat this setup
script when changing the display or the DPI scaling factor/percentage.

2. Alternatively, as pointed out by Rich, one can patch the X11
configuration to make sure that Tk will return the correct [tk scaling]
value. However, only a tiny minority of the end users is able and/or
willing to do this, for good reasons. And what are the necessary steps
on Windows? I have no idea, and I am not sure that this is even
possible with reasonable amount of work (again, on the end user's side!).

3. What would be the benefit from getting 5 cm both on a large 24"
display with 96 dots/inch and on a small 14" screen with 160 dots/inch
for a GUI element that was created using "-width 5c"? Let alone the
case of a tablet or even smartphone. The smaller the device, the
shorter the reading distance, hence it appears to me to be quite normal
that the resulting physical size reflects the viewing distance, too. My
original posting addressed a misbelief of Alex, who thought that 1c will
appear as 1 cm on every screen. If this were a fact rather than a
misunderstanding then he would also be right when stating that using
points or centimeters rather than pixels is equivalent to using absolute
physical sizes.

4. Let's assume for a moment that the Tk implementation or X11 and
Windows are being changed in such a way that "-width 5c" results in an
absolute physical size of 5 cm, regardless of the display's physical
size, resolution, and pixel density. What would then be the correct way
to develop scalable Tk GUIs? Currently we are preaching to the Tk
newbies that they should use screen distances and font sizes in points
rather than pixels, along with images that are either scalable or are
provided in several sizes (like 16x16, 24x24, etc.). By respecting
these rules, one can indeed make sure that the GUI will look as expected
on a great variety of screens, and this is not *in spite* of the fact
that 5c not always means 5 cm, but *because* this is the common
behavior, regardless of whether we view it as a bug or feature.

[nemethi]

Am 23.10.20 um 03:05 schrieb Rich:

I agree with you that this is at any rate the common behavior. Whether
we view it as correct or bogus, depends on whether we expect the 5 cm on
our display or on a reference screen having 96 DPI instead. Since the
documentation is missing any reference to this detail, one can call it a
bug, but this doesn't automatically imply that it is an implementation
one. It can also be interpreted as a bug in the documentation of a de
facto standard common behavior.

>> On my 14" notebook I have not only Windows 10 but also three different
>> Linux distributions. On Windows, if the DPI scaling is set to 100 %
>> then [tk scaling] will be 1.333.... You stated that this is because
>> "W10 may also be lying about the physical screen resolution". Please
>> note that I get the same [tk scaling] value on Linux, too.
>> Consequently, not only Windows, but also Linux (more precisely, X11) is
>> "lying about the physical screen resolution". Indeed, [winfo
>> screenmmwidth .] is 508 both on my 24" display and on the 14" notebook
>> screen, *not only on Windows, but also on Linux*. This value, together
>> with [winfo screenwidth .], which is 1920 on both displays, regardless
>> of the windowing system, explains why we get the same initial [tk
>> scaling] value of 1.333... on both Windows and Linux.
>
> I've subsequently found this
> https://bugs.freedesktop.org/show_bug.cgi?id=23705 which while somewhat
> rambling, seems to indicate that at some point, X11 was modified to
> assume 96dpi /unless/ the user provides a DisplaySize parameter in
> one's xorg.conf file, and to ignore the EDID resoluton values reported
> from monitors. It also implies that ignoring the EDID was intentional
> because, according to a few comments inside, manufactures often provide
> incorrect EDID values, resulting in bogus DPI computations. So, yes,
> it does appear that later X releases have begun /lying/ about the
> screen's DPI value, unless the owner knows that they need to tell X
> their screens physical size in the xorg.conf file.

This seems to confirm what I wrote about a 96 DPI reference screen. And
that this "lie" in X11 about the screen's DPI value is more than 10
years old.

>
> I got the result of 1c == 1c on my screen because as it happens, it is
> just shy of the default 96dpi that X chooses (actual DPI is a few
> hundredths less than 94dpi). So I got 1c == 1c with Brad's example.
>
> I then used xrandr to adjust my dpi settings and tested again. First,
> I told X to use a dpi of 96*2 (192 dpi). Running the test, I got a 1c
> wide box, and these tk scaling factors:
> a: 2.6687680588389804
> b: 4.003152088258471
>
> Then, I told X the screen dpi was 96/2 (48 dpi). Running the test I
> got a 0.5c wide box, and these tk scaling factors:
> a: 0.6667979261009384
> b: 4.003152088258471
>
> So, for at least X11 (I don't have windows installed anywhere to test
> with), if the dpi of the monitor is set properly, Tk computes a correct
> scaling factor to give a real 5cm line when asking for a 5cm line.
>

This contradicts Brad's statement about a "buggy Tk core code". At
least on X11.

I agree, but IMHO, what the vast majority of Tk applications needs, is a
reasonable appearance on displays of different sizes, resolutions, pixel
densities, and scaling factors, rather than accurate physical sizes on
the screen.

>
> I also expect that if you calculate the resolution of your laptop
> screen, and tell X11 the real world resolution (xrandr --dpi #) that
> Brad's example will give you a 1cm sized red box on the laptop.
>

Yes, it behaves as expected.

[nemethi]

Am 23.10.20 um 16:41 schrieb nemethi:

"their are" -> "there are", sorry!

[Brad Lanam]

On Friday, October 23, 2020 at 7:41:45 AM UTC-7, nemethi wrote:
> 3. What would be the benefit from getting 5 cm both on a large 24"
> display with 96 dots/inch and on a small 14" screen with 160 dots/inch
> for a GUI element that was created using "-width 5c"? Let alone the
> case of a tablet or even smartphone. The smaller the device, the
> shorter the reading distance, hence it appears to me to be quite normal
> that the resulting physical size reflects the viewing distance, too. My
> original posting addressed a misbelief of Alex, who thought that 1c will
> appear as 1 cm on every screen. If this were a fact rather than a
> misunderstanding then he would also be right when stating that using
> points or centimeters rather than pixels is equivalent to using absolute
> physical sizes.

This has already been addressed in this discussion.
There are two different schools of thought for scaling applications.

[Ri Ho]

Here is our real-world solution: a client uses off-site reps, who, we were told had surface pros configured with a screen resolution of 1920x1080, all scaled correctly via the MS Windows settings that provides for improving the appearance of apps "that might look blurry...".

NOT!

in fact, some of the reps had tablets with res: 2560x1440, the expected 1920x1080 and (get ready for this) 1366x768. (Let's step over the issue of IT remote management - this is the era of covid, ain't going to happen.)

Consider, as well, the aforementioned challenges of not only different resolutions; but also, physical screen size.

Our solution (for what it is worth), was to develop the UI on a 1920x1080 (confirming tcl reporting same pixel res as windows settings). All widgets were 'place'd, with the desired size and placement (all in pixels). Following this, all widget geometries were converted to a floating point, relative values.

It was the use of these values that assured the delivered UI was consistent across all platforms.

That means: a button that appears in the upper left-hand corner of the toplevel, appears in the same location regardless of res or size. Same for the text box that appears in the lower right corner.

That is key, as far a uniformity of experience is mandated. eg. no scrolling regardless of res or size (and whether or not they ever get the surface pros)

However, absolute sizing is not acceptable. It is ok for a widget to be 5cm on a 22in screen, but not on a 13in screen.

Issues: We need a way to convert png images used as background content to svg, with color information preserved. Any suggestions would really be appreciated!!
Challenges: In some instances the users has set the MS Windows "Advanved scalling settings" in such a way that UI, ours and others, were effectively magnified.
Those people needed to be dope-slapped!

Well, that;s my 2 cents worth (inflation, exchange rates - not considered)