New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
window placement issue in multi-mon environment #1595
Comments
Restoring window geometry in X11 is very hard, maybe even impossible in some cases. :( I can add option to disable the geometry restoring on application side and leave it to the window manager. |
If it's not crazy amount of effort, might make sense to make it a togglable option. |
The problem is that it may work even worse when it's disabled. BTW, you can check the debug logs for window geometry (store/restore operations); in copyq exit
COPYQ_LOG_LEVEL=DEBUG copyq |& grep -i geometry Moving and resizing window should print "Save geometry ..." message; reopening window should print "Restore geometry ...". |
Weirdest thing, after restarting the server it's working fine now.
Then after opening copyq on screen 1 and then manually dragging it from screen 0 to 1, the geometry file had contents in the initial post. Edit, also, can see that the geometry file now looks like this:
So there might be an issue with storing the geometry, but once it's there it's all good. Quite confident that manual window moving was the fix, as the current OS install has been live for ~couple of weeks now, and this is the first time the window placement works as expected. |
Hmm, let me try to review the source code. There is probably some inconsistency in the option names when geometry is stored and restored. |
There's something more at play here. After restarting X the issue came about again. As previously, restarting copyq fixed it. Could there be a race condition between xrandr and copyq? As in xserver is started, copyq starts, xrandr configures external monitors. Which likely would also have implications on (re-)docking a computer. I'll try to gather some debug output for |
I found out that, at least on Wayland, restoring window geometry on a screen with a higher DPI did not work properly (a7d1609). Not sure if it's a Qt/Wayland bug. NOTE: This problem would show up in debug logs ( |
FWIW: there have been changes in that regard in CopyQ 4 - in case you want to try / verify it there. |
I have the problem that it is not showing up properly when run from the laptop's screen (eDP1), which is right of the external screen:
I have "Open windows on current screen" checked, using X.org with awesomeWM. First I've opened it on the external screen four times (given the shortcut); the first two lines include the message from startup.
When opening it on the internal screen it does not show up at all (I've minimized/maximized it here):
And then resized it using awesomeWM (using a keyboard shortcut for the focused, but invisible window):
Opening it again made it not show up again then:
Note the property name for the internal screen: "Options/MainWindow_geometry_960x540", in contrast to the external one ("Options/MainWindow_geometry_screen_1").
|
@blueyed does restarting copyq process help in any way after all the screens have been attached? |
@laur89
On this (X.org) display it looks like this, opening it a few times on the internal screen:
On the external display:
Resized/moved the window, which did not save the position, but the width/height only:
|
Any input here? But it might actually also be fixable like you've imagined:
(Just to clarify: it was working before, and I've kept using an older version for a while due to this.) |
Sure. Quick fix here: #1802 |
I'm trying to improve the window-geometry-restore behavior in fc30712. |
Describe the bug
Copyq window placement is erratic. In my setup it's okay on the leftmost screen (screen 2), okay-ish on screen 0 (laptop internal screen, right-most display) with the caveat that the window is always placed on top-left corner on screen 0. However, opening copyq when screen 1 is active, the behavior is as if it were opened on screen 0, as in cursor is moved to screen 0 and window is positioned there in the top-left corner.
a) when screen 1 is active and copyq is toggled, it opens on screen 0 as described above.
b) while the window is opened, the user drags it left onto screen 1
c) copyq window is closed
d) copyq is toggled (still being on screen 1)
e) window opens correctly in the position it was previously closed on, ie on screen 1
f) window is closed
g) copyq is toggled again -> we're back to start, ie window gets opened on screen 0 again
Displays are positioned, from left-to-right, as 2,1,0. Also note screen 1 is in portrait. screenshot from arandr showing the screen placement.
copyq_geometry.ini:
copyq.conf
Using i3 window manager.
The text was updated successfully, but these errors were encountered: