Move window to another monitor failed
XFCE 4.18
Moving window to another monitor does not work on my end. I see the following in .xsession-errors when trying to move a window.
(xfwm4:4216): xfwm4-CRITICAL **: 21:41:45.815: getMoveToMonitorProps: assertion 'other_rect->y == current_rect->y + current_rect->height' failed
(xfwm4:4216): xfwm4-CRITICAL **: 21:41:45.817: clientMoveToMonitorByDirectionTarget: assertion 'candidate_monitors != NULL' failed
(xfwm4:4216): xfwm4-CRITICAL **: 21:41:45.817: clientMoveToMonitorByDirection: assertion 'target != NULL' failedMy laptop ux8402 has two monitors. I also cannot see the "move to another monitor" submenu when right-clicking the window title.
Activity
/cc @intensity
cat /tmp/xrandr.txt Screen 0: minimum 320 x 200, current 1727 x 1599, maximum 16384 x 16384 eDP-1 connected 1728x1080+0+0 (normal left inverted right x axis y axis) 312mm x 195mm 2880x1800 120.00*+ 2880x1620 59.96 59.97 2560x1600 59.99 59.97 2560x1440 59.99 59.99 59.96 59.95 2048x1536 85.00 75.00 60.00 1920x1440 85.00 75.00 60.00 1856x1392 75.00 60.01 1792x1344 75.00 60.01 2048x1152 59.99 59.98 59.90 59.91 1920x1200 59.88 59.95 1920x1080 60.01 59.97 59.96 59.93 1600x1200 85.00 75.00 70.00 65.00 60.00 1680x1050 84.94 74.89 69.88 59.95 59.88 1600x1024 60.17 1400x1050 85.00 74.76 70.00 59.98 1600x900 59.99 59.94 59.95 59.82 1280x1024 85.02 75.02 60.02 1440x900 59.89 1400x900 59.96 59.88 1280x960 85.00 60.00 1440x810 60.00 59.97 1368x768 59.88 59.85 1360x768 59.80 59.96 1280x800 59.99 59.97 59.81 59.91 1152x864 100.00 85.06 85.00 75.00 75.00 70.00 60.00 1280x720 60.00 59.99 59.86 59.74 1024x768 85.00 75.05 60.04 85.00 75.03 70.07 60.00 1024x768i 86.96 960x720 85.00 75.00 60.00 928x696 75.00 60.05 896x672 75.05 60.01 1024x576 59.95 59.96 59.90 59.82 960x600 59.93 60.00 832x624 74.55 960x540 59.96 59.99 59.63 59.82 800x600 85.00 75.00 70.00 65.00 60.00 85.14 72.19 75.00 60.32 56.25 840x525 85.02 74.96 69.88 60.01 59.88 864x486 59.92 59.57 800x512 60.17 700x525 85.08 74.76 70.06 59.98 800x450 59.95 59.82 640x512 85.02 75.02 60.02 720x450 59.89 700x450 59.96 59.88 640x480 85.09 60.00 85.01 72.81 75.00 59.94 720x405 59.51 58.99 720x400 85.04 684x384 59.88 59.85 680x384 59.80 59.96 640x400 59.88 59.98 85.08 576x432 100.11 85.15 85.09 75.00 75.00 70.00 60.06 640x360 59.86 59.83 59.84 59.32 640x350 85.08 512x384 85.00 75.03 70.07 60.00 512x384i 87.06 512x288 60.00 59.92 416x312 74.66 480x270 59.63 59.82 400x300 85.27 72.19 75.12 60.32 56.34 432x243 59.92 59.57 320x240 85.18 72.81 75.00 60.05 360x202 59.51 59.13 360x200 85.04 320x200 85.27 320x180 59.84 59.32 320x175 85.27 DP-1 connected primary 1728x519+0+1081 (normal left inverted right x axis y axis) 310mm x 90mm 2880x864 120.02 + 60.01* 1366x768 59.79 1360x768 60.02 1280x800 84.88 74.93 59.81 1152x864 75.00 1280x768 84.84 74.89 59.87 1280x720 60.00 1024x768 85.00 75.03 70.07 60.00 800x600 85.06 72.19 75.00 DP-2 disconnected (normal left inverted right x axis y axis) DP-3 disconnected (normal left inverted right x axis y axis) HDMI-1 disconnected (normal left inverted right x axis y axis)
From a user perspective i've narrowed down the issue to display scaling (is that the right term?) like in the screenshots above.
If I use
1xscaling inead of0.6xthemove_to_monitorfeature works. I switched to DPI scaling in the fonts settings instead of the above scaling for now, which seems to work/look much better than in 4.16 and even better than display scaling.Maybe this information helps to fix the issue when scaling in the display settings is active. Let me know if i can do anything else related to this issue.
Thanks for reporting this one, indeed your debugging will help fix it. The move to monitor feature requires monitors to be "touching" on an edge, so it might be off by some small factor (or simply float rounding).
I'll run some tests to reproduce in the next day or 2 and see how easy of a fix this may be.
For me moving to another monitor works, however I get critical warnings when right-clicking on the titlebar of a SSD window.
If only one monitor is plugged:
(xfwm4:103760): xfwm4-CRITICAL **: 17:02:52.891: clientMoveToMonitorByDirectionTarget: assertion 'candidate_monitors != NULL' failed (xfwm4:103760): xfwm4-CRITICAL **: 17:02:52.891: clientMoveToMonitorByDirectionTarget: assertion 'candidate_monitors != NULL' failed (xfwm4:103760): xfwm4-CRITICAL **: 17:02:52.891: clientMoveToMonitorByDirectionTarget: assertion 'candidate_monitors != NULL' failed (xfwm4:103760): xfwm4-CRITICAL **: 17:02:52.892: clientMoveToMonitorByDirectionTarget: assertion 'candidate_monitors != NULL' failedIf two monitors are plugged:
(xfwm4:103760): xfwm4-CRITICAL **: 17:02:35.885: getMoveToMonitorProps: assertion 'other_rect->x == current_rect->x + current_rect->width' failed (xfwm4:103760): xfwm4-CRITICAL **: 17:02:35.885: clientMoveToMonitorByDirectionTarget: assertion 'candidate_monitors != NULL' failed (xfwm4:103760): xfwm4-CRITICAL **: 17:02:35.886: getMoveToMonitorProps: assertion 'current_rect->y == other_rect->y + other_rect->height' failed (xfwm4:103760): xfwm4-CRITICAL **: 17:02:35.886: clientMoveToMonitorByDirectionTarget: assertion 'candidate_monitors != NULL' failed (xfwm4:103760): xfwm4-CRITICAL **: 17:02:35.886: getMoveToMonitorProps: assertion 'other_rect->y == current_rect->y + current_rect->height' failed (xfwm4:103760): xfwm4-CRITICAL **: 17:02:35.886: clientMoveToMonitorByDirectionTarget: assertion 'candidate_monitors != NULL' failedOk I've taken a look and there's 2 things happening here.
The
xfwm-CRITICALlog messagesThese log messages are generated by the g_return_val_if_fail macro.
This is my fault, as I (never having coded much with glib before) saw them in other parts of the code, and was using them as regular flow-control.
I'll replace them all with if-statements so these don't show up unnecessarily.
The move to monitor functionality doesn't work
This is caused by a slight misalignment when using scaling. Printing out the current/other monitor positions being considered, we get things like
(x, y, width, height):current (0, 0, 2048, 1152) other (2047, 0, 2048, 1152)This sounds very much like a rounding issue somewhere, and may or may not be intentional. When having my monitors scaled I do notice a single pixel of the first monitor's (maximized) window showing on the second.
@olivier I'm thinking of mitigating this by changing the
==check to<= 2px, do you think that sounds fair?I'll also submit an issue about the overflow when using scaling. @robberer can you check if you also had that single pixel bleed-over from one monitor to the next?
mentioned in merge request !104 (merged)
I put !104 (merged) to resolve the issue. @robberer can you comment on #695 (moved) if you had the same issue when using scaling? Thanks!
This feature doesn't work properly for me, either, and I think I have slightly different problems than the reports in this thread so far.
In contrast to the OP, I don't use scaling!
I use a laptop (left) and two external 27" screens (middle and right). When I first attached the screens to the laptop, everything worked fine, but now I cannot get it to work anymore, although I deleted the saved profile, disconnected and reconnected the screens. Here's what happens: I have
Super+Shift+LeftandSuper+Shift+Rightmapped tomove to left/right monitor. The shortcut forMove to left monitorworks flawlessly, but the shortcut formove to right monitordoesn't work at all. However (!), right clicking on the window bar, thenmove to other monitorand selectingright monitorworks, which seems really surprising to me because I would have expected this to be the same feature under the hood.For
move to left monitorshortcut (which works) the.xsession-errorsshows this:(xfwm4:1292): xfwm4-CRITICAL **: 09:59:27.018: getMoveToMonitorProps: assertion 'current_rect->x == other_rect->x + other_rect->width' failedFor
move to right monitorshortcut, simply nothing happens, and no entries in.xsession-errorsare created.For
move to left monitorandmove to right monitorusing the window titlebar (which works) I get a lot of spam, which is probably related to theg_return_val_if_failthing mentioned above:(xfwm4:1292): xfwm4-CRITICAL **: 10:02:26.560: getMoveToMonitorProps: assertion 'current_rect->x == other_rect->x + other_rect->width' failed (xfwm4:1292): xfwm4-CRITICAL **: 10:02:26.560: getMoveToMonitorProps: assertion 'other_rect->x == current_rect->x + current_rect->width' failed (xfwm4:1292): xfwm4-CRITICAL **: 10:02:26.560: getMoveToMonitorProps: assertion 'other_rect->x == current_rect->x + current_rect->width' failed (xfwm4:1292): xfwm4-CRITICAL **: 10:02:26.560: clientMoveToMonitorByDirectionTarget: assertion 'candidate_monitors != NULL' failed (xfwm4:1292): xfwm4-CRITICAL **: 10:02:26.560: getMoveToMonitorProps: assertion 'current_rect->y == other_rect->y + other_rect->height' failed (xfwm4:1292): xfwm4-CRITICAL **: 10:02:26.560: getMoveToMonitorProps: assertion 'current_rect->y == other_rect->y + other_rect->height' failed (xfwm4:1292): xfwm4-CRITICAL **: 10:02:26.560: clientMoveToMonitorByDirectionTarget: assertion 'candidate_monitors != NULL' failed (xfwm4:1292): xfwm4-CRITICAL **: 10:02:26.560: getMoveToMonitorProps: assertion 'other_rect->y == current_rect->y + current_rect->height' failed (xfwm4:1292): xfwm4-CRITICAL **: 10:02:26.560: getMoveToMonitorProps: assertion 'other_rect->y == current_rect->y + current_rect->height' failed (xfwm4:1292): xfwm4-CRITICAL **: 10:02:26.560: clientMoveToMonitorByDirectionTarget: assertion 'candidate_monitors != NULL' failed (xfwm4:1292): xfwm4-CRITICAL **: 10:02:29.320: getMoveToMonitorProps: assertion 'current_rect->x == other_rect->x + other_rect->width' failed (xfwm4:1292): xfwm4-CRITICAL **: 10:02:57.511: getMoveToMonitorProps: assertion 'current_rect->x == other_rect->x + other_rect->width' failed (xfwm4:1292): xfwm4-CRITICAL **: 10:02:57.512: getMoveToMonitorProps: assertion 'other_rect->x == current_rect->x + current_rect->width' failed (xfwm4:1292): xfwm4-CRITICAL **: 10:02:57.512: getMoveToMonitorProps: assertion 'current_rect->y == other_rect->y + other_rect->height' failed (xfwm4:1292): xfwm4-CRITICAL **: 10:02:57.512: getMoveToMonitorProps: assertion 'current_rect->y == other_rect->y + other_rect->height' failed (xfwm4:1292): xfwm4-CRITICAL **: 10:02:57.512: clientMoveToMonitorByDirectionTarget: assertion 'candidate_monitors != NULL' failed (xfwm4:1292): xfwm4-CRITICAL **: 10:02:57.512: getMoveToMonitorProps: assertion 'other_rect->y == current_rect->y + current_rect->height' failed (xfwm4:1292): xfwm4-CRITICAL **: 10:02:57.512: getMoveToMonitorProps: assertion 'other_rect->y == current_rect->y + current_rect->height' failed (xfwm4:1292): xfwm4-CRITICAL **: 10:02:57.512: clientMoveToMonitorByDirectionTarget: assertion 'candidate_monitors != NULL' failed (xfwm4:1292): xfwm4-CRITICAL **: 10:02:58.993: getMoveToMonitorProps: assertion 'other_rect->x == current_rect->x + current_rect->width' failedHere's the output of xrandr:
Screen 0: minimum 320 x 200, current 7040 x 1440, maximum 16384 x 16384 eDP connected 1920x1080+0+360 (normal left inverted right x axis y axis) 309mm x 174mm 1920x1080 60.05*+ 1680x1050 60.05 1280x1024 60.05 1440x900 60.05 1280x800 60.05 1280x720 60.05 1024x768 60.05 800x600 60.05 640x480 60.05 HDMI-A-0 connected 2560x1440+4480+0 (normal left inverted right x axis y axis) 597mm x 336mm 2560x1440 59.95*+ 1920x1200 59.95 2048x1080 60.00 1920x1080 60.00 50.00 59.94 1600x1200 60.00 1680x1050 59.88 1280x1024 75.02 60.02 1440x900 59.95 1280x800 59.91 1152x864 75.00 1280x720 60.00 50.00 59.94 1024x768 75.03 60.00 800x600 75.00 60.32 720x576 50.00 720x480 60.00 59.94 640x480 75.00 60.00 59.94 720x400 70.08 DisplayPort-0 disconnected (normal left inverted right x axis y axis) DisplayPort-1 disconnected (normal left inverted right x axis y axis) DisplayPort-2 connected primary 2560x1440+1920+0 (normal left inverted right x axis y axis) 597mm x 336mm 2560x1440 59.95*+ 1920x1200 59.88 2048x1080 60.00 1920x1080 60.00 50.00 59.94 1600x1200 60.00 1680x1050 59.95 1280x1024 75.02 60.02 1280x800 59.81 1152x864 75.00 1280x720 60.00 50.00 59.94 1024x768 75.03 60.00 800x600 75.00 60.32 720x576 50.00 720x480 60.00 59.94 640x480 75.00 60.00 59.94 720x400 70.08 DisplayPort-3 disconnected (normal left inverted right x axis y axis)I guess that's not a lot of information to go from. Let me know if there's another log-file than
.xsession-errorsthat might have more helpful info.Edited by Bago HartWait, nevermind, it seems that this is a keyboard issue – super+shift+left is recognized correctly, but super+shift+right is not recognized at all. When I use the external keyboard, everything works as expected. This is a weird bug that I don't understand yet, but it seems to not have to do anything with this issue. o_O
@olivier in reference to your comments in !104 (merged):
I wonder why the code needs to be so strict about the layout though.
I understand this is to deal with setup with more than two monitors, it has to pick the closest one in the layout.
Maybe a more flexible approach would be to find the best monitor, picking the closest one even though it's not strictly contiguous?
The existing solution is fairly simple in that it 1) Must be contiguous 2) Favours one with more overlap perpendicular to the desired direction. However as soon as I try to drop the "must be contiguous" constraint (which I agree should be dropped), I spiral into philosophy!
Consider these 6 example 3-monitor configurations:
A little exaggerated I know, but good for philosophical discussion. In each example, we're on monitor 1, and thus there's 3 potential movements we could reasonably consider:
- Move right to monitor 2
- Move right to monitor 3 (directly, not "via monitor 2")
- Move down to monitor 2
So let's consider the examples, and the argument for each.
- Example 1
- Move right to monitor 2? Probably, as there is overlap, and one could imagine a setup like this when using 3 "horizontal" monitors.
- Move right to monitor 3? Probably not, as 2 really seems a better choice.
- Move down to monitor 2? Probably, it's more right than down, but there is horizontal overlap.
- Example 2
- Move right to monitor 2? Maybe, the centre of 2 is very low though, and 3 seems a better choice.
- Move right to monitor 3? Probably, it's much more "right" than 2.
- Move down to monitor 2? Yes I think so.
- Example 3
- Move right to monitor 2? Probably not, as there's no overlap, and 3 seems a better choice.
- Move right to monitor 3? Probably, as it's vertically aligned and there's no better choice.
- Move down to monitor 2? Yes I think so.
- Example 4
- Move right to monitor 2? Probably not, even though its centre is to the right, it feels like it's not really "right" of 1.
- Move right to monitor 3? Yes I think so.
- Move down to monitor 2? Yes definitely.
- Example 5
- Move right to monitor 2? Probably not, as with example 3 the centroid is very low, and especially now because it compasses the entire horizontal portion of 1.
- Move right to monitor 3? Yes I think so.
- Move down to monitor 2? Yes definitely.
- Example 6
- Move right to monitor 2? No, for the same reasons as example 3.
- Move right to monitor 3? Yes, as 2 really doesn't sound like a good candidate for "right".
- Move down to monitor 2? Yes definitely.
In all of this, there are really 4 factors I'm really looking at:
- How much overlap there is perpendicular to the direction of travel (when moving right, consider vertical overlap). This is why in example 1 I say monitor 2 can be considered "right", while in example 3 it shouldn't.
- How much overlap there is in the same direction as the travel (when moving right, consider horizontal overlap). This is why in example 4 I hesitate to say monitor 2 should be considered "right" of monitor 1.
- Angle between the centre of each monitor, relative to direction of travel. This is why in example 1 I say monitor 2 is right, but not so much in example 2.
- Offset in the desired movement direction. This is why in example 1 I favour monitor 2 for "right" over monitor 3.
To add to the above 4 factors, in example 1 thoughts, I've selected monitor 2 as a candidate for both right and down. This leads to 2 similar but not equivalent questions:
- Should a monitor be a candidate for more than 1 direction?
- If so, should we allow the monitor to win both directions, and indeed show both?
If we say yes to Q1 but no to Q2, then we could hit some odd scenarios. Consider this setup:
- We're using example 1 setup
- Monitor 3 is off, so only 1/2 are active
- We're on monitor 1
- Monitor 2 is considered a candidate for both right and down, but "right" is preferred, so only that is shown.
- Now we plug in monitor 3, and we consider it a better candidate for "right".
- Because monitor 3 is preferred for "right", monitor 2 now doesn't win that, but does still win "down", so that option can be displayed (because it's no longer winning "right" also).
- In adding a monitor to the right, the "down" option became available.
I'm not saying such an outcome would be "wrong", but it doesn't "sound" right.
In terms of actually putting together a valid algorithm for this, I'm only at constraints based on factors 1/2:
- Require some overlap perpendicular to direction of travel to eliminate bad candidates. This eliminates going "right to monitor 2" in examples 3/6.
- Overlap in the direction of travel is conditional in both boundaries. That is, if you're going right, the min-x and max-x of the monitor you're going from must be lower than the monitor you're going to. This eliminates going "right to monitor 2" in examples 4/5/6.
This is only good for elimination though, choosing a "best" is really tough, and keeps leaning towards a weighted sum of factors or something similar, which doesn't seem right (e.g. adding "angle between centres" with "overlap perpendicular to direction of travel").
I'll keep mulling it over, but if you find yourself with too much time, I'd love to hear your thoughts.
-
Closing this issue since it was fixed by !104 (merged).
