Wrong Tiling Pie Menu position

[auipga]

Describe the bug
When I use the Tiling Pie Menu on a 2nd/3rd monitor, it is displaced about have a screen to the right. 1st monitor works fine.

Steps To Reproduce
Add a 2nd monitor to your setup.
The resolution seems not to be relevant.
Hold Super, click right mouse. Don't move.

Screenshots/-captures

System Info:

• Distro (incl. version): Arch Linux (rolling)
• GNOME version: 40.2
• Extensions version: 21
• Wayland: 1.19.0 (X won't even trigger the Pie Menu but rather the application context menu)

Journalctl logs
looks unrelated:

libinput error: client bug: timer event24 debounce short: scheduled expiry is in the past (-12ms), your system is too slow
libinput error: client bug: timer event24 debounce short: scheduled expiry is in the past (-12ms), your system is too slow
libinput error: client bug: timer event24 debounce: scheduled expiry is in the past (-9ms), your system is too slow
libinput error: client bug: timer event24 debounce short: scheduled expiry is in the past (-22ms), your system is too slow
libinput error: client bug: timer event24 debounce: scheduled expiry is in the past (-6ms), your system is too slow
libinput error: client bug: timer event24 debounce short: scheduled expiry is in the past (-19ms), your system is too slow

Additional context

• I thought it might be this edge case setup.
  
  So I tried with 2x FHD next to each other (without offset) and above each other (without offset too). I thougt the displacement could be on the y axis instead of x axis. Still the same x-axis offset.
• While still holding Super I can move my mouse to use the 4 assigned actions like normal (although I don't hover them). The Deadzone on the other hand can only be triggered by moving the mouse exactly over it (about 700px exactly 1080px to the right).
• As soon as I initiate the Tiling Pie Menu on the third monitor, it's not visible anymore. (I think the bug applies twice then)
• Edit 1: With the offset between monitor 3/left and 2/center (as pictured above) there is an y-offset of about exactly that.

  xrandr --current | grep connected
  XWAYLAND0 connected primary 3440x1440+1080+0 (normal left inverted right x axis y axis) 800mm x 340mm
  XWAYLAND1 connected 1920x1080+4520+139 (normal left inverted right x axis y axis) 290mm x 170mm
  XWAYLAND2 connected 1080x1920+0+360 (normal left inverted right x axis y axis) 190mm x 340mm
  

• Edit 2: added measured pixels. => It is exactly X+1080 and Y+360 (see Edit 1)

[auipga]

deprecated get_monitor_geometry in tilingPieMenu.js#L38

Retrieves the Rectangle representing the size and position of the individual monitor within the entire screen area.

deprecated get_pointer in tilingPieMenu.js#L54

Gets the current location of the pointer and the current modifier mask for a given display.

[Leleat]

Thanks for the detailed report. I'll fix it.

[auipga]

Theoretical steps:

1. Change get_monitor_geometry in tilingPieMenu.js#L38
   use the whole Screen (like xrandr | grep Screen -> 6440 x 2280)

OR

2. change get_pointer in tilingPieMenu.js#L54
   use the pointer position relative to the current Monitor

Practrical steps:
What I tried and what does not work (I don't have a clue of Gdk).
If you read this, and you know what to do, you are allowed to laugh ;)

// original
const {x, y, width, height} = global.display.get_monitor_geometry(global.display.get_current_monitor());
// experiments
const {x, y, width, height} = global.monitor.get_geometry(global.display.get_current_monitor());
const {x, y, width, height} = global.display.get_geometry();
const {x, y, width, height} = global.display.get_monitor_workarea(global.display.get_current_monitor());
const {x, y, width, height} = global.display.get_current_monitor().get_geometry();
const {x, y, width, height} = global.display.get_default().get_current_monitor().get_geometry();
const {x, y, width, height} = gdk_monitor_get_geometry(global.display.get_current_monitor());

@Leleat do you think, you can find a solution within the next days?

[Leleat]

Sorry, didn't have time yesterday. Just pushed a new commit. Only tested it briefly cause I usually don't run a multimonitor setup (so I had to use my laptop + monitor). Can you test it as well and see, if it's fixed for you as well?

Wayland: 1.19.0 (X won't even trigger the Pie Menu but rather the application context menu)

I am also running an X Session usually and this didn't happen to me. Dumb question but did you disable the pie menu on your X session? Or do you have any other extensions, which might conflict with this (kinda weird that it would work on your Wayland session though...)?

PS. I've got no clue about Gdk either. But this is Mutter (https://gjs-docs.gnome.org/meta8~8_api/). No idea how those 2 relate exactly since I am learning by searching through the docs :P.

[auipga]

Confirming 15ea4db fixes this.

[auipga]

Or do you have any other extensions, which might conflict [...] ?

gsettings get org.gnome.shell enabled-extensions has 80 commas. I'll check them some day.

[auipga]

The Pie Menu has been blocked by the Animation Tweaks extension, to be precise its Open and Close effects of Window Menu.

Screenshot for reference (with only the conflicting effect disabled)

#61 is begging for an update ;)

Edit:
To prevent this you could run sth. like this in extension.js enable()

dconf read /org/gnome/shell/extensions/animation-tweaks/windowmenu-close | cut -d"," -f2 | grep -q "T" \
 || dconf read /org/gnome/shell/extensions/animation-tweaks/windowmenu-open | cut -d"," -f2 | grep -q "T" \
 || return;
notify-send "please disable animation..."

[Leleat]

The Pie Menu has been blocked by the Animation Tweaks extension, to be precise its Open and Close effects of Window Menu.

#61 is begging for an update ;)

Thanks for the fast repsonse. Added to the incompatibility list :)

To prevent this you could run sth. like this in extension.js enable()

This would only catch the case of both extension being enabled on startup (of gnome shell). But I guess it's better than nothing, so I'll add it, thanks.

Edit:
Nvm, I am not gonna add a message / compatibility check. The settings persist, even if the extension (Animation Tweaks) is removed or disabled. That means the user would get notified on every startup... I could check the state of Animation Tweaks but since the extension init order is random (I think), it would be unreliable/hacky.