Hello,
when trying to resize a maximized window, the actual window on win32 doesn't change, but it seems that the application window is resized.
See attached screenshot.
Looks like gtk thinks that we are resizing the window, but win32 does not allow it? Do you have any debug log from the client and server doing this? Does this happen with any app or just this one?
Debug log? What do you need exactly?
Anything related to window dimensions? Any clue in there? (and is it specific to one app, or many, etc..)
You can reproduce the issue easily.
Start a Xpra server and start Paraview (it needs OpenGL to run, so "vglrun paraview" is usually needed). Connect to the server with the windows client.
Maximize the window. Try to resize it. See what happens.
100% reproducible, no need for vglrun or win32, works with xdummy.
Looks like the client and server disagree on whether the window is resizable, so we end up resizing the server window but not the client window... which leaves junk pixels in between.
I assume you mean the opposite: we're resizing the client window but not the server's?
No, just like I said above. More details below.
(this with lxde/openbox - maybe other window managers do things differently) I can resize the window horizontally OR vertically, and everything resizes correctly (on the fly too). It only goes wrong when I resize both dimensions in one go.
I believe that's because the resizing is done by the application itself and not the window manager: there are no "do_configure_event
"s firing. The widget in the window's bottom-right corner does not belong to the client's window manager.
Whatever the application is doing, it should be telling us (the server) that it is resizing itself, why are we not seeing that?
In fact, everything works fine if you manage to use your client's window manager to do the resizing and not the application's widget. For openbox, that means grabbing the thin outer edge of the window. You can see the change to the window's widget because the cursor also changes (the app uses a "double arrow", my local window manager uses a "corner with arrow pointing to it").
I can see the resize events in x_event_filter
:
ConfigureNotify 22 event received: (0, 0, 1769, 1004) ConfigureNotify 22 event received: (0, 0, 1699, 925) ConfigureNotify 22 event received: (0, 0, 1683, 910) ConfigureNotify 22 event received: (0, 0, 1679, 907) ConfigureNotify 22 event received: (0, 0, 1674, 903) ConfigureNotify 22 event received: (0, 0, 1626, 861)
But this never reaches anywhere in xpra's window event handlers!?
On the subject of move/resize, I found this in the ewmh spec:
Window Managers should treat a _NET_MOVERESIZE_WINDOW message exactly like a ConfigureRequest (in particular, adhering to the ICCCM rules about synthetic ConfigureNotify events), except that they should use the gravity specified in the message. Rationale: Using a _NET_MOVERESIZE_WINDOW message with StaticGravity allows Pagers to exactly position and resize a window including its decorations without knowing the size of the decorations.
Which we do not handle at present... needs adding.
Looks like the app is sending the resize (ConfigureNotify
event) to the wrong window.
So the "right" fix is to fix the app, I am now looking at finding a workaround by catching resize events sent to the "composite helper" and forwarding those to the correct window. That's a bit of a hack though, and might cause further problems with apps that do *not* misbehave... And so far, all I've managed to do is to prevent the client window from resizing the composite window it does not own (which is probably better behaviour than what we have now)
# The purpose of the 'corral' is to keep the client window managed -- we # select for SubstructureRedirect on it, so that the client cannot resize # etc. without going through the WM.
Well..
composite_configure_event(..) event.geometry: (0, 0, 1473, 687) composite_configure_event(..) corral_window: (2, 23, 2039, 1164, 24) composite_configure_event(..) client_window: (0, 0, 1473, 687, 24)
Maybe we need ResizeRedirect
too?
Anyway, I was completely wrong about the size handling: we just don't handle client (as in X11 client) side window resizing at all, which is the problem. See r912 for a simple test app which shows the problem much more simply than paraview.
The solution is not simple: if we pass the new window dimensions (and position whilst we are at it) to the client, we risk creating loops.
work in progress patch, definitely not ready for merging, but should work
The patch above fixes the issue, but may well introduce new ones... Like loops where the client and the server keep resizing the windows to match their own sizing constraints... Will need thorough testing (and test apps) on all platforms, and the wimpiggy bits are probably misnamed (need cleaning up)
cleaner version of the patch merged in r1089
I haven't encountered any loops yet... but if there are some, we should be able to do something about it:
idle_add
call - after checking that the size is not too far out, and if it is.. ??)
Note: see #765 for _NET_MOVERESIZE_WINDOW
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/107