[noborder patch] window hangs after `movemouse`
jdujava opened this issue · 4 comments
Consider a window which has a "hidden" border by means of the noborder patch. It appears that the window hangs (visually) after moving it using the mouse (by movemouse function).
This doesn't happen when resizing using the mouse (by resizemouse function), moreover the action of resizing restores the "normal" state when window was "hanging". If a window was floating beforehand (and thus had a border), moving it with the mouse works without issues.
To reproduce:
- apply
noborderpatch - open any window on an empty tag, so it doesn't have a border (e.g. terminal)
- move it using the mouse (by
movemousefunction) - the window is now floating, still without border, and visually doesn't respond to any action (e.g. typing in terminal)
- resize the window using the mouse (by
resizemousefunction) - the window acquires the border and is fully functioning, also shows changes made earlier (e.g. the characters were really typed in terminal, they just waren't shown..)
Can you also reproduce the issue? Do you have any idea what is causing it or how to fix it?
This issue is present either with dwm-fullscreen-compilation-noborder, or just with a plain noborder patch, so the problem must somehow be hidden in changing the border width of a window.
Other minor things:
- toggling the floating state of a widnow by a shortcut leaves the window without the border
- other way round, when a window is floating (with border) and resized to the whole screen, toggling the floating state leaves the border present.
If I inspected the code correctly, this is because border removing/restoring is done in resizeclient function, which however is not called when the window already has the appropriate size. Would be awesome to tackle all the issues all at once if possible 😃.
The noborder patch is notorious for having weird compatibility issues.
I wasn't able to reproduce this with dwm-flexipatch, bare dwm + noborder patch or with bare dwm + dwm-fullscreen-compilation-noborder.
visually doesn't respond to any action (e.g. typing in terminal)
To be honest that kind of sounds like the compositor is in the way, I think I have seen that one before, possibly in relation to noborder (not 100% sure though). Worth checking if killing the compositor makes the terminal visually responsive when this happens.
In resizeclient we call XConfigureWindow with the instructions to draw the window without the border and this is where the noborder patch applies the logic to reduce the border width to 0.
Then we have that resizeclient also calls configure - because some windows need it. Here the border width is also sent via XSendEvent. I have learnt that the noborder logic should also be applied here to cover for edge cases.
In my case what I found was that some GTK applications would resize when the border is removed, but would leave graphical artefacts on the bottom and on the right hand side due to some confusion about the window size.
As for the other thing that would be due to resizeclient not being triggered due to size hints (applied in resize). It is possible to call resizeclient directly rather than going through resize, but that will result in other issues such as size hints not being applied at all. I suppose that it would be possible to take the noborder logic into account in applysizehints as well to work around this issue. But as you can see it is starting to get a bit ridiculous :)
To be honest that kind of sounds like the compositor is in the way, I think I have seen that one before, possibly in relation to noborder (not 100% sure though). Worth checking if killing the compositor makes the terminal visually responsive when this happens.
You are right! Without running xcompmgr I cannot reproduce the issue. I suppose there isn't a simple fix without changing the compositor, but maybe I should consider swiching to something else.
As for the other thing that would be due to resizeclient not being triggered due to size hints (applied in resize). It is possible to call resizeclient directly rather than going through resize, but that will result in other issues such as size hints not being applied at all. I suppose that it would be possible to take the noborder logic into account in applysizehints as well to work around this issue. But as you can see it is starting to get a bit ridiculous :)
Indeed, thanks anyway for the insights 👍.
This is another fix I applied a while back. Perhaps see if that makes any difference in your case?