Problems understanding winfo rootx and vrootx

[Alexandru]

I have problems understanding the commands "winfo rootx" and "winfo vrootx"

winfo rootx window
Returns a decimal string giving the x-coordinate, in the root window of the screen, of the upper-left corner of window's border (or window if it has no border).

winfo vrootx window
Returns the x-offset of the virtual root window associated with window, relative to the root window of its screen. This is normally either zero or negative. Returns 0 if there is no virtual root window for window.

I think the definition of rootx is actually clear.
But how can I immagine vrootx?
I get that it's about having two screens, right?
Why is it zero or negative?
Can someone explain this in detail?

Many thanks
Alexandru

[Alexandru]

Another question: Under which circumstances does the vrootx/vrooty return negative values?

[briang]

Hi Alexandru,

The vroot is only relevant when when there are multiple physical displays and the desktop spans all displays and the individual display retains it's own coordinates. The value returned is the distance from the given window from the virtual origin of the combined displays. This origin should be in the top left corner of the left most physical display, provided of course that the displays are configured correctly. It's negative because if it was positive it would imply that the window is to the left and/or above the left top most point on the combined display. The vrootx has the potential to be negative only when vrootwidth != screenwidth.

It's been a long time since I've had to deal with this, so my memory could be misguided.

-Brian

[Alexandru]

Thanks Brian!
One customer is having issues when my app is opening new toplevels an he's using two screens with different resolutions.
I couldn't reproduce the issue on my two screens... I suppose, it's happening when vrootx/y is returning negative values. In my case, it's always zero not matter what I do.
What should I do in order to get negative values for e.g. "winfo vrooty ." ?
Cheers
Alex

[Christian Gollwitzer]

Am 30.01.21 um 10:18 schrieb Alexandru:

I haven't tested it, but I can imagine the following: With two screens,
make the right one the primary screen and the left screen the secondary
screen. Then I can imagine that the right screen starts at (0,0) and if
you move the app to the left screen, it could have negative x coordinates.

Christian

[Alexandru]

Good point. But what about the y coordinate? This is actually the issue for my customer...

[Uwe Klein]

Am 30.01.21 um 13:39 schrieb Alexandru:

> Good point. But what about the y coordinate? This is actually the issue for my customer...
>

This is afaics not about dual screens or not.

it is about a virtual screen that is larger than the physical screen(s)

you could configure the xserver to have a virtual screen of forex
2000x1000 pixels.

while the monitor would not display more than 800x600
access was managed by moving the mouse to the hard screen borders for
panning.

fvwm2 allowed to configure the pager to be a pager of virtual screens.

These features seem to have been forgotten. Just like remote display
options.

Uwe

[Alexandru]

Okay, so I need to robustly position a toplevel window on the screen. Do I need to alway subtract the values of vrootx and vrooty from those of rootx and rooty?

[Brad Lanam]

On Saturday, January 30, 2021 at 4:40:02 AM UTC-8, Alexandru wrote:
> Good point. But what about the y coordinate? This is actually the issue for my customer...

You can put the secondary screen on top of the primary screen for testing purposes.
I am guessing your customer has different sized screens, where one is larger than the other.

[Brad Lanam]

This is what I have. It's been a very long time since I wrote this, but I think it generally works.
set sh [winfo vrootheight .]
set sw [winfo vrootwidth .]
set vrootx [winfo vrootx .]
set vrooty [winfo vrooty .]
...
# check if the window is off-screen and if so, move it elsewhere.
if { $y > [expr {$sh - 10 + $vrooty}] || $y < [expr {0 + $vrooty}]} {
set y 27
}

[Brad Lanam]

I should have copied a bit more code. I get 'y' from the [wm geometry ...] of the window.

set geom [wm geometry $w]
regexp {=?((\d+)x(\d+))?([+-])(-?\d+)([+-])(-?\d+)} \
$geom all wwwh ww wh xoff x yoff y

When I save the window geometry, I convert any negative right edge offsets to a positive number.
(I think Windows returns negative offsets on occasion).

[briang]

On Saturday, January 30, 2021 at 7:08:08 AM UTC-8, Brad Lanam wrote:

The tkdiff utility has a good example of vroot use, and it is well documented code.
https://sourceforge.net/p/tkdiff/code/HEAD/tree/trunk/tkdiff
Look for proc ::combobox::ComputeGeometry

-Brian

[Alexandru]

Thanks Christian, that helped. Now I can reproduce this result. I just switched the order of the screens.
But still, I cannot reproduce the issue on the computer of a customer, where a second toplevel is positioned such that the title bar gets hidden so that it's impossible to trag the new window to a new position.
The code is simple:

toplevel $w
# Window always on top
wm transient $w .
# Position the toplevel relative to main window
set wx [winfo rootx .]
set wy [winfo rooty .]
wm geometry $w +$wx+$wy

This code works for me on two screens, but it doesn't work on the two screens of my customer.

[briang]

Here are a few points to consider:
* Be careful to use the toplevel widget and not any internal widgets or frames when setting the geometry of the window. The internals will be offset from their containing frame.
* Some window managers don't include the window manager decoration in the window size information. (This decoration, the outermost frame of the window, is not controlled by Tk.) So when it is positioned, it can be off by the decoration amount. This is typically more dramatic in the Y direction.
* Saving and restoring window positions can be problematic if the display characteristics change between application sessions. Some kind of amelioration should be available/implemented if this happens to cause a window to be out-of-frame. I've always added a binding to a spot in the lower-right corner that would perform a drag (move) of the window. There's always some dead space there anyway, and it's useful to have in various scenarios.

These problems are more prevalent in linux environments with it's plethora of window managers.

[Alexandru]

I took a look at the proposed procedure and, as expected it adds vrooty to rooty.
But if I do this in my application , when using two screens, then the result is wrong positioning of the toplevel.