Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Starting to play with Tk

98 views
Skip to first unread message

Cecil Westerhof

unread,
Dec 18, 2017, 8:14:05 PM12/18/17
to
I just started with:
http://www.tkdocs.com/tutorial/firstexample.html

The problem is that I have a high resolution monitor and it is quit
tiny. How can I increase the size so it becomes a bit better readable?

--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

Rich

unread,
Dec 18, 2017, 9:19:31 PM12/18/17
to
Cecil Westerhof <Ce...@decebal.nl> wrote:
> I just started with:
> http://www.tkdocs.com/tutorial/firstexample.html
>
> The problem is that I have a high resolution monitor and it is quit
> tiny. How can I increase the size so it becomes a bit better readable?

At some point in your script (near the beginning is a good place) you
can run this loop to boost all of the font sizes:

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

The 16 there means "16 point". Tk's defaults are pixels (negative
sizes mean pixels), and on a high-dpi monitor, a 12 pixel font (Tk's
default size) is /tiny/.

Cecil Westerhof

unread,
Dec 19, 2017, 4:14:06 AM12/19/17
to
Works like a charm. Thanks.


It is probably not possible, but it does not hurt to ask. ;-)

I have also a normal monitor. It would be plausible that I move a
window from the High Res monitor to the normal one. Would it be
possible to reset the fonts for that one back to 12?

Rich

unread,
Dec 19, 2017, 5:45:30 AM12/19/17
to
There's a two part answer here.

1) Reset the fonts? Yes, you can change the font sizes at any time
and the widgets using those fonts will adjust to the new size.

2) Can you detect when the window moves between monitors so you can
'know' when to change the font size? This is more difficult, as the
answer highly depends upon how your system presents itself to Tk. You
can certianly setup a motion event handler to watch the position on
screen of the window, and then knowing ahead of time where the boundary
is between the two screens, it can decide when to change the font
sizes. But this will be specific to your screens and not a general
purpose solution. Without an extension, I am unaware of a true general
purpose way to handle detecting which physical screen a window is
positioned upon.

Cecil Westerhof

unread,
Dec 19, 2017, 6:28:06 AM12/19/17
to
Rich <ri...@example.invalid> writes:

> Cecil Westerhof <Ce...@decebal.nl> wrote:
>> Rich <ri...@example.invalid> writes:
>>
>>> Cecil Westerhof <Ce...@decebal.nl> wrote:
>>>> I just started with:
>>>> http://www.tkdocs.com/tutorial/firstexample.html
>>>>
>>>> The problem is that I have a high resolution monitor and it is quit
>>>> tiny. How can I increase the size so it becomes a bit better readable?
>>>
>>> At some point in your script (near the beginning is a good place) you
>>> can run this loop to boost all of the font sizes:
>>>
>>> foreach font [font names] { font configure $font -size 16 }
>>>
>>> The 16 there means "16 point". Tk's defaults are pixels (negative
>>> sizes mean pixels), and on a high-dpi monitor, a 12 pixel font (Tk's
>>> default size) is /tiny/.
>>
>> Works like a charm. Thanks.
>>
>>
>> It is probably not possible, but it does not hurt to ask. ;-)
>>
>> I have also a normal monitor. It would be plausible that I move a
>> window from the High Res monitor to the normal one. Would it be
>> possible to reset the fonts for that one back to 12?
>
> There's a two part answer here.
>
> 1) Reset the fonts? Yes, you can change the font sizes at any time
> and the widgets using those fonts will adjust to the new size.

That is good news: I did not expect that. For example with Clojure you
have to do it before displaying: after it is not possible anymore.

There is only one problem: I could have several windows and some on
the high res one and some on the normal one.

But may I should learn to walk before I am going to run. And learning
to crawl before going to walk. ;-)


> 2) Can you detect when the window moves between monitors so you can
> 'know' when to change the font size? This is more difficult, as the
> answer highly depends upon how your system presents itself to Tk. You
> can certianly setup a motion event handler to watch the position on
> screen of the window, and then knowing ahead of time where the boundary
> is between the two screens, it can decide when to change the font
> sizes. But this will be specific to your screens and not a general
> purpose solution. Without an extension, I am unaware of a true general
> purpose way to handle detecting which physical screen a window is
> positioned upon.

For me that is not that important. I can just add a button or checkbox
to toggle the two modes.

Rich

unread,
Dec 19, 2017, 6:44:18 AM12/19/17
to
Tk contains an amazing amount of run-time adaptability. You can change
most anything and (presuming options settings that authorize the
change) most things will resize/change/adjust to the change all
automatically under the hood.

> There is only one problem: I could have several windows and some on
> the high res one and some on the normal one.

Each widget defaults to one of the Tk default font names. But you can,
if you want, create new font names for your windows and assign those
fonts to your widgets in those windows. Taken to the logical end
point, each window's widgets could reference a set of font names
specific to that window. Then changing those font parameters will
effect only that window, not the others.

> But may I should learn to walk before I am going to run. And learning
> to crawl before going to walk. ;-)

True, and while creating custom font names is easy, and using those
custom names for widgets is easy, doing so on a window by window basis
adds unneeded complexity while you are still coming up to speed.

>> 2) Can you detect when the window moves between monitors so you can
>> 'know' when to change the font size? This is more difficult, as the
>> answer highly depends upon how your system presents itself to Tk. You
>> can certianly setup a motion event handler to watch the position on
>> screen of the window, and then knowing ahead of time where the boundary
>> is between the two screens, it can decide when to change the font
>> sizes. But this will be specific to your screens and not a general
>> purpose solution. Without an extension, I am unaware of a true general
>> purpose way to handle detecting which physical screen a window is
>> positioned upon.
>
> For me that is not that important. I can just add a button or checkbox
> to toggle the two modes.

Yes, this is the easiest solution to determining "what font size should
show" based upon which monitor the window resides upon.

Cecil Westerhof

unread,
Dec 19, 2017, 7:28:06 AM12/19/17
to
Rich <ri...@example.invalid> writes:

> Tk contains an amazing amount of run-time adaptability. You can change
> most anything and (presuming options settings that authorize the
> change) most things will resize/change/adjust to the change all
> automatically under the hood.

Very good to know. :-D


>> There is only one problem: I could have several windows and some on
>> the high res one and some on the normal one.
>
> Each widget defaults to one of the Tk default font names. But you can,
> if you want, create new font names for your windows and assign those
> fonts to your widgets in those windows. Taken to the logical end
> point, each window's widgets could reference a set of font names
> specific to that window. Then changing those font parameters will
> effect only that window, not the others.

Good point. Thanks.


>> But may I should learn to walk before I am going to run. And learning
>> to crawl before going to walk. ;-)
>
> True, and while creating custom font names is easy, and using those
> custom names for widgets is easy, doing so on a window by window basis
> adds unneeded complexity while you are still coming up to speed.

Yes. But it is reassuring to know that it is there when I will need
it. :-D

>>> 2) Can you detect when the window moves between monitors so you can
>>> 'know' when to change the font size? This is more difficult, as the
>>> answer highly depends upon how your system presents itself to Tk. You
>>> can certianly setup a motion event handler to watch the position on
>>> screen of the window, and then knowing ahead of time where the boundary
>>> is between the two screens, it can decide when to change the font
>>> sizes. But this will be specific to your screens and not a general
>>> purpose solution. Without an extension, I am unaware of a true general
>>> purpose way to handle detecting which physical screen a window is
>>> positioned upon.
>>
>> For me that is not that important. I can just add a button or checkbox
>> to toggle the two modes.
>
> Yes, this is the easiest solution to determining "what font size should
> show" based upon which monitor the window resides upon.

Cecil Westerhof

unread,
Dec 19, 2017, 8:14:05 AM12/19/17
to
Rich <ri...@example.invalid> writes:

>> For me that is not that important. I can just add a button or checkbox
>> to toggle the two modes.
>
> Yes, this is the easiest solution to determining "what font size should
> show" based upon which monitor the window resides upon.

Done. I created the following proc for it:
proc switchFont {} {
if {${::fontSize} eq 12} {
set ::fontSize 16
} else {
set ::fontSize 12
}
foreach font [font names] {
font configure ${font} -size ${::fontSize}
}
}

But it has a strange problem. At the start the window is changed as it
should to the correct dimensions. But at the moment I place the window
on the other monitor the window is not resized when changing the font
size.

What could be the problem?

Rich

unread,
Dec 19, 2017, 1:01:03 PM12/19/17
to
Cecil Westerhof <Ce...@decebal.nl> wrote:
> Rich <ri...@example.invalid> writes:
>
>>> For me that is not that important. I can just add a button or checkbox
>>> to toggle the two modes.
>>
>> Yes, this is the easiest solution to determining "what font size should
>> show" based upon which monitor the window resides upon.
>
> Done. I created the following proc for it:
> proc switchFont {} {
> if {${::fontSize} eq 12} {
> set ::fontSize 16
> } else {
> set ::fontSize 12
> }
> foreach font [font names] {
> font configure ${font} -size ${::fontSize}
> }
> }
>
> But it has a strange problem. At the start the window is changed as it
> should to the correct dimensions. But at the moment I place the window
> on the other monitor the window is not resized when changing the font
> size.
>
> What could be the problem?

To answer that you'll need to post a minimal failing example (there are
too many other possibilities that could be the cause to guess which one
accurately).

Cecil Westerhof

unread,
Dec 19, 2017, 2:14:04 PM12/19/17
to
The following code reproduces it on my system:
#!/usr/bin/env tclsh


package require Tk


proc switchFont {} {
if {${::fontSize} eq 12} {
set ::fontSize 16
} else {
set ::fontSize 12
}
foreach font [font names] {
font configure ${font} -size ${::fontSize}
}
}

proc getCPUTemp {{clean false}} {
if {1 != [regexp -all -line {^CPU_TEMP: +([^ ]+) } [exec sensors] -> temp]} {
error {Did not get exactly a single line from [exec sensors] output}
}
if {${clean}} {
string range ${temp} 1 [expr [string length ${temp}] - 3]
} else {
return ${temp}
}
}

proc updateCPUTemp {} {
set ::temp [getCPUTemp]
puts [format "%s: %s" [clock format [clock seconds] -format %T] ${::temp}]
after [expr {(60 - ([clock seconds] % 60)) * 1000}] updateCPUTemp
}


set fontSize 12
switchFont
wm title . "Show CPU Temperature"
grid [ttk::label .temp -textvariable temp]
bind . <1> {switchFont}
updateCPUTemp


As long as I stay on the same monitor, the dimensions of the window
are changed when the fonts change. But at the moment I go to another
window the dimensions are frozen.
It is just as if Tk thinks I manually changed the dimensions.

Rich

unread,
Dec 19, 2017, 2:45:26 PM12/19/17
to
The first thing I see is that you have not informed 'grid' as to how
you want the rows/columns in the grid to expand/contract in response to
size changes (grid's default is to not change size after initial
update).

Look into the -weight option to the rowconfigure and columnconfigure
options to the grid manager.

As to why it waits until you move to the other monitor before things
'lock', that I don't know why at the moment (onl have one monitor here
right now, so could not test a two monitor setup if I wanted to do so).

It is possible that adding a -weight to tell grid how to reapportion
space for expand/contract might fix the issue for the second monitor.

Cecil Westerhof

unread,
Dec 19, 2017, 4:44:06 PM12/19/17
to
Rich <ri...@example.invalid> writes:

> The first thing I see is that you have not informed 'grid' as to how
> you want the rows/columns in the grid to expand/contract in response to
> size changes (grid's default is to not change size after initial
> update).
>
> Look into the -weight option to the rowconfigure and columnconfigure
> options to the grid manager.
>
> As to why it waits until you move to the other monitor before things
> 'lock', that I don't know why at the moment (onl have one monitor here
> right now, so could not test a two monitor setup if I wanted to do so).
>
> It is possible that adding a -weight to tell grid how to reapportion
> space for expand/contract might fix the issue for the second monitor.

Nope, the code below gives the same problem:
#!/usr/bin/env tclsh


proc doWorkTerminal {} {
source /usr/local/share/tcltk/utilities.tcl
while {True} {
updateCPUTemp
puts "${::time}: ${::temp}"
waitMinutes 1
}
}

proc doWorkTk {} {
package require Tk
wm attributes . -topmost 1
#wm resizable . 0 0
set ::fontSize 12
switchFont
wm title . "Show CPU Temperature"
grid [ttk::frame .c -padding "3 3 12 12"]
grid columnconfigure . 0 -weight 1
grid rowconfigure . 0 -weight 1
grid [ttk::label .c.time -textvariable ::time] -column 1 -row 1 -sticky e
grid [ttk::frame .c.space -width 16 ] -column 2 -row 1 -sticky ew
grid [ttk::label .c.temp -textvariable ::temp] -column 3 -row 1 -sticky w
bind . <1> {switchFont}
updateCPUTempLoop
}

proc getCPUTemp {{clean false}} {
if {1 != [regexp -all -line {^CPU_TEMP: +([^ ]+) } [exec sensors] -> temp]} {
error {Did not get exactly a single line from [exec sensors] output}
}
if {${clean}} {
string range ${temp} 1 [expr [string length ${temp}] - 3]
} else {
return ${temp}
}
}

proc switchFont {} {
if {${::fontSize} eq 12} {
set ::fontSize 16
} else {
set ::fontSize 12
}
foreach font [font names] {
font configure ${font} -size ${::fontSize}
}
}

proc updateCPUTemp {} {
set ::temp [getCPUTemp]
set ::time [clock format [clock seconds] -format "%T"]
}

proc updateCPUTempLoop {} {
updateCPUTemp
after [expr {(60 - ([clock seconds] % 60)) * 1000}] updateCPUTempLoop
}


if {(${argc} == 1) && ([lindex $argv 0] == "--Tk")} {
doWorkTk
} else {
doWorkTerminal
}

With:
wm resizable . 0 0

There is no problem. That would work in this case (there is no reason
to resize), but certainly not in all cases.


I also made it so it can be switched to terminal or Tk.

Rich

unread,
Dec 19, 2017, 4:59:34 PM12/19/17
to
Cecil Westerhof <Ce...@decebal.nl> wrote:
> Rich <ri...@example.invalid> writes:
>
>> The first thing I see is that you have not informed 'grid' as to how
>> you want the rows/columns in the grid to expand/contract in response
>> to size changes (grid's default is to not change size after initial
>> update).
>>
>> Look into the -weight option to the rowconfigure and columnconfigure
>> options to the grid manager.
>>
>> As to why it waits until you move to the other monitor before things
>> 'lock', that I don't know why at the moment (onl have one monitor
>> here right now, so could not test a two monitor setup if I wanted to
>> do so).
>>
>> It is possible that adding a -weight to tell grid how to reapportion
>> space for expand/contract might fix the issue for the second
>> monitor.
>
> Nope, the code below gives the same problem:
[long code block snipped.]

I generally put my 'columnconfigure' and 'rowconfigure' calls after I
pack widgets into the grid. I don't know if it really makes a
difference, but doing so 'after' guarantees the rows and/or columns do
in fact exist before trying to configure them.

> With:
> wm resizable . 0 0
>
> There is no problem.

Meaning the window resizes when the font changes?

If turning off the ability to interactively resize results in an
auto-resize then this implies a weird interaction with whatever window
manager is running on your system. In which case the lack of resize
when moved to the other monitor may not be Tk's fault or even under the
app's control.

> That would work in this case (there is no reason to resize), but
> certainly not in all cases.

Yes.

I'll be able to test later (although I'll have to edit your script, as
what you posted won't run for me on my system without removing the
specifics to your system) on two monitors, but one of them is not a
high-dpi monitor, so it won't be a perfect test.

Cecil Westerhof

unread,
Dec 19, 2017, 7:59:05 PM12/19/17
to
Rich <ri...@example.invalid> writes:

> Cecil Westerhof <Ce...@decebal.nl> wrote:
>> Rich <ri...@example.invalid> writes:
>>
>>> The first thing I see is that you have not informed 'grid' as to how
>>> you want the rows/columns in the grid to expand/contract in response
>>> to size changes (grid's default is to not change size after initial
>>> update).
>>>
>>> Look into the -weight option to the rowconfigure and columnconfigure
>>> options to the grid manager.
>>>
>>> As to why it waits until you move to the other monitor before things
>>> 'lock', that I don't know why at the moment (onl have one monitor
>>> here right now, so could not test a two monitor setup if I wanted to
>>> do so).
>>>
>>> It is possible that adding a -weight to tell grid how to reapportion
>>> space for expand/contract might fix the issue for the second
>>> monitor.
>>
>> Nope, the code below gives the same problem:
> [long code block snipped.]
>
> I generally put my 'columnconfigure' and 'rowconfigure' calls after I
> pack widgets into the grid. I don't know if it really makes a
> difference, but doing so 'after' guarantees the rows and/or columns do
> in fact exist before trying to configure them.

Well, I have to try that again later. But with other code, because I
have implemented the stripchart, so font does not have much influence
anymore.


>> With:
>> wm resizable . 0 0
>>
>> There is no problem.
>
> Meaning the window resizes when the font changes?

Exactly.


> If turning off the ability to interactively resize results in an
> auto-resize then this implies a weird interaction with whatever window
> manager is running on your system. In which case the lack of resize
> when moved to the other monitor may not be Tk's fault or even under the
> app's control.
>
>> That would work in this case (there is no reason to resize), but
>> certainly not in all cases.
>
> Yes.
>
> I'll be able to test later (although I'll have to edit your script, as
> what you posted won't run for me on my system without removing the
> specifics to your system) on two monitors, but one of them is not a
> high-dpi monitor, so it won't be a perfect test.

In my case one monitor is a high-dpi and the other a normal one.

It is running on Debian 9.

Rich

unread,
Dec 19, 2017, 8:24:28 PM12/19/17
to
Cecil Westerhof <Ce...@decebal.nl> wrote:
> grid [ttk::frame .c -padding "3 3 12 12"]
> grid columnconfigure . 0 -weight 1
> grid rowconfigure . 0 -weight 1
> grid [ttk::label .c.time -textvariable ::time] -column 1 -row 1 -sticky e
> grid [ttk::frame .c.space -width 16 ] -column 2 -row 1 -sticky ew
> grid [ttk::label .c.temp -textvariable ::temp] -column 3 -row 1 -sticky w

You have two layers of grids here. You have . being gridded,
containing a single frame .c.

Then you have .c containing a nested grid, which hold .c.time .c.space
.c.temp.

You only set row/col configure on the outer . grid, but nothing on the
nested .c grid. So the nested grid will not expand/contract in
response to size changes. That may be why your layout didn't work to
resize (although yours above resized for me perfectly on my two monitor
system (running Fvwm2 as the WM)).

Also, you do not need the outer frame above, you can achieve a similar
layout with:

grid [ttk::label .time -textvariable ::time] -column 1 -row 1 -sticky e -pady {3 3} -padx {12 0}
grid [ttk::frame .space -width 16 ] -column 2 -row 1 -sticky ew
grid [ttk::label .temp -textvariable ::temp] -column 3 -row 1 -sticky w -padx {0 12}

Rich

unread,
Dec 19, 2017, 8:27:40 PM12/19/17
to
Yes, there you'd have to (if possible) reconfigure the stripchart to
'zoom' (if that is possible) or to just redraw it larger/smaller as
need be.

>>> With:
>>> wm resizable . 0 0
>>>
>>> There is no problem.
>>
>> Meaning the window resizes when the font changes?
>
> Exactly.

Very odd. And this fact implies that the oddness may possibly be
window manager related.

>> If turning off the ability to interactively resize results in an
>> auto-resize then this implies a weird interaction with whatever window
>> manager is running on your system. In which case the lack of resize
>> when moved to the other monitor may not be Tk's fault or even under the
>> app's control.
>>
>>> That would work in this case (there is no reason to resize), but
>>> certainly not in all cases.
>>
>> Yes.
>>
>> I'll be able to test later (although I'll have to edit your script, as
>> what you posted won't run for me on my system without removing the
>> specifics to your system) on two monitors, but one of them is not a
>> high-dpi monitor, so it won't be a perfect test.
>
> In my case one monitor is a high-dpi and the other a normal one.
>
> It is running on Debian 9.

Debian 9 is your Linux distribution, but not your "window manager". I
don't know what is Deb 9's default wm, but then you might be running
something else besides the default wm.

Cecil Westerhof

unread,
Dec 20, 2017, 3:59:06 AM12/20/17
to
Just copying stuff. Just started with Tk (and Tcl), so I have a lot to
learn still.

When I have a little time (spend way to much) I will tryout this.

Cecil Westerhof

unread,
Dec 20, 2017, 3:59:06 AM12/20/17
to
Rich <ri...@example.invalid> writes:

> Cecil Westerhof <Ce...@decebal.nl> wrote:
>>> I generally put my 'columnconfigure' and 'rowconfigure' calls after I
>>> pack widgets into the grid. I don't know if it really makes a
>>> difference, but doing so 'after' guarantees the rows and/or columns do
>>> in fact exist before trying to configure them.
>>
>> Well, I have to try that again later. But with other code, because I
>> have implemented the stripchart, so font does not have much influence
>> anymore.
>
> Yes, there you'd have to (if possible) reconfigure the stripchart to
> 'zoom' (if that is possible) or to just redraw it larger/smaller as
> need be.

That is something I have to find out yet.


>>>> With:
>>>> wm resizable . 0 0
>>>>
>>>> There is no problem.
>>>
>>> Meaning the window resizes when the font changes?
>>
>> Exactly.
>
> Very odd. And this fact implies that the oddness may possibly be
> window manager related.

OK, well I am curious what will happen on your system. :-)


>> It is running on Debian 9.
>
> Debian 9 is your Linux distribution, but not your "window manager". I
> don't know what is Deb 9's default wm, but then you might be running
> something else besides the default wm.

I should have been a little bit more specific. :'-( Especially because
I do not use the default wm. I am using xfwm4 (Xfce4 wm).

Rich

unread,
Dec 20, 2017, 12:44:33 PM12/20/17
to
The origional looked like the 'style' that was used before the grid
manager arrived, back when Tk had just place and pack. Frames used as
containers were often the only way obtain a desired layout.

With grid, many of the multiple nested frames layouts from the past can
be done with just grid in a single container. So there's less often a
need for a 'frame' holder anymore.

> When I have a little time (spend way to much) I will tryout this.

No hurries.

Rich

unread,
Dec 20, 2017, 1:58:33 PM12/20/17
to
Cecil Westerhof <Ce...@decebal.nl> wrote:
> Rich <ri...@example.invalid> writes:
>> Cecil Westerhof <Ce...@decebal.nl> wrote:
>>>> Rich <ri...@example.invalid> writes:
>>>>
>>>> Meaning the window resizes when the font changes?
>>>
>>> Exactly.
>>
>> Very odd. And this fact implies that the oddness may possibly be
>> window manager related.
>
> OK, well I am curious what will happen on your system. :-)

Works just fine for me, on dual monitors, with Fvwm2.

>>> It is running on Debian 9.
>>
>> Debian 9 is your Linux distribution, but not your "window manager".
>> I don't know what is Deb 9's default wm, but then you might be
>> running something else besides the default wm.
>
> I should have been a little bit more specific. :'-( Especially
> because I do not use the default wm. I am using xfwm4 (Xfce4 wm).

Ok, since you don't use the default wm anyway, would there be any
chance you would be willing to temporarially run a different wm to see
if the issue is possibly wm related?

Cecil Westerhof

unread,
Dec 20, 2017, 2:44:06 PM12/20/17
to
Rich <ri...@example.invalid> writes:

> Cecil Westerhof <Ce...@decebal.nl> wrote:
>> Rich <ri...@example.invalid> writes:
>>> Cecil Westerhof <Ce...@decebal.nl> wrote:
>>>>> Rich <ri...@example.invalid> writes:
>>>>>
>>>>> Meaning the window resizes when the font changes?
>>>>
>>>> Exactly.
>>>
>>> Very odd. And this fact implies that the oddness may possibly be
>>> window manager related.
>>
>> OK, well I am curious what will happen on your system. :-)
>
> Works just fine for me, on dual monitors, with Fvwm2.

But are they different monitors? In my case one is high resolution and
the other not. Also one is landscape and one is portrait positioned.
(If that could make a difference.)


>>>> It is running on Debian 9.
>>>
>>> Debian 9 is your Linux distribution, but not your "window manager".
>>> I don't know what is Deb 9's default wm, but then you might be
>>> running something else besides the default wm.
>>
>> I should have been a little bit more specific. :'-( Especially
>> because I do not use the default wm. I am using xfwm4 (Xfce4 wm).
>
> Ok, since you don't use the default wm anyway, would there be any
> chance you would be willing to temporarially run a different wm to see
> if the issue is possibly wm related?

It would be interesting to see if it makes a difference. Have to see
how to install and use Fvwm2.


By the way: Xcfe seems to be based on Fvmm.

Rich

unread,
Dec 20, 2017, 3:30:20 PM12/20/17
to
Cecil Westerhof <Ce...@decebal.nl> wrote:
> Rich <ri...@example.invalid> writes:
>
>> Cecil Westerhof <Ce...@decebal.nl> wrote:
>>> Rich <ri...@example.invalid> writes:
>>>> Cecil Westerhof <Ce...@decebal.nl> wrote:
>>>>>> Rich <ri...@example.invalid> writes:
>>>>>>
>>>>>> Meaning the window resizes when the font changes?
>>>>>
>>>>> Exactly.
>>>>
>>>> Very odd. And this fact implies that the oddness may possibly be
>>>> window manager related.
>>>
>>> OK, well I am curious what will happen on your system. :-)
>>
>> Works just fine for me, on dual monitors, with Fvwm2.
>
> But are they different monitors? In my case one is high resolution and
> the other not. Also one is landscape and one is portrait positioned.
> (If that could make a difference.)

Well, different in that they are two different models, from two
different makers, with two different pixel width/length sizes. Both,
however, are roughly 92dpi monitors, so they do not markedly differ in
pixel density.

>>>>> It is running on Debian 9.
>>>>
>>>> Debian 9 is your Linux distribution, but not your "window manager".
>>>> I don't know what is Deb 9's default wm, but then you might be
>>>> running something else besides the default wm.
>>>
>>> I should have been a little bit more specific. :'-( Especially
>>> because I do not use the default wm. I am using xfwm4 (Xfce4 wm).
>>
>> Ok, since you don't use the default wm anyway, would there be any
>> chance you would be willing to temporarially run a different wm to see
>> if the issue is possibly wm related?
>
> It would be interesting to see if it makes a difference. Have to see
> how to install and use Fvwm2.
>
> By the way: Xcfe seems to be based on Fvmm.

Fair enough. I don't know what it is based upon. It would be a way to
possibly implicate the wm. In that if you try a different wm, with the
remainder identical, and the issue disappears, you can point a finger
at Xfce as the possible culprit.

If you try a different wm (or a couple different wm's) and it persists,
then it is not the wm. This also means we are no closer to finding the
culprit as well.

0 new messages