#2457 closed defect (fixed)
xpra start gnome-terminal window "is jumpy"
Reported by: | stdedos | Owned by: | stdedos |
---|---|---|---|
Priority: | blocker | Milestone: | 4.0 |
Component: | client | Version: | 3.0.x |
Keywords: | Cc: |
Description (last modified by )
$ xpra version xpra for python 2.7 is not installed retrying with python3 3.0-r24095 $ lsb_release -rd Description: Ubuntu 16.04.6 LTS Release: 16.04
client:
Windows 10 Xpra GTK3 client version 4.0-r24195 64-bit
For a lack of .... any good description, I'll let the video explain the issue :-)
It seems to "hate more" being "widened" than being "heightened".
Attachments (3)
Change History (17)
Changed 3 years ago by
Attachment: | xpra-client_2019-10-19_12-54-27.mp4 added |
---|
comment:1 Changed 3 years ago by
Description: | modified (diff) |
---|---|
Owner: | changed from Antoine Martin to stdedos |
Changed 3 years ago by
Attachment: | xpra-client-2457.txt added |
---|
Changed 3 years ago by
Attachment: | display-:20.log added |
---|
comment:2 Changed 3 years ago by
I would guess that the "plain" one does not contain anything (many connections and disconnections, I'd assume the files are lost already)
-d geometry
is extremely chatty, apologies for that. I am attaching files instead.
Are there "other variables" available at log-file = display-$DISPLAY.log
configuration option?
Maybe I'd like to add $timestamp
also? Then I could have some history (as long as PC does not shutdown itself, at least)
comment:3 Changed 3 years ago by
Owner: | changed from stdedos to Antoine Martin |
---|
comment:4 Changed 3 years ago by
Owner: | changed from Antoine Martin to Antoine Martin |
---|---|
Priority: | critical → blocker |
Status: | new → assigned |
According to mailing list: Beta problems some geometry problems are present in 4.0-r24287, but not in 3.0-r24039.
comment:5 Changed 3 years ago by
Maybe I'd like to add $timestamp also? Then I could have some history (as long as PC does not shutdown itself, at least)
r24348 adds TIMESTAMP
(uppercase to keep things more consistent)
As for the geometry bug:
- the xterm window is created as (server side):
initial X11 position and size: requested((0, 0, 499, 316), {'base-size': (19, 4), 'increment': (6, 13), 'gravity': 1, 'minimum-size': (25, 17)})=(0, 0, 499, 316) setup() hints={'base-size': (19, 4), 'increment': (6, 13), 'gravity': 1, 'minimum-size': (25, 17)} size=499x316 calc_constrained_size(499, 316, {'base-size': (19, 4), 'increment': (6, 13), 'gravity': 1, 'minimum-size': (25, 17)})=(499, 316) (size_constraints=(0, 0, 32767, 32767)) setup() resizing windows to 499x316
- the client creates it, but the geometry gets rounded down for some reason:
process_new_common: wid=1, OR=False, geometry([0, 0, 499, 316])=(0, 0, 499, 316) / (499, 316) ['configure-window', 1, 211, 245, 495, 305, {'encodings.rg..]}, 'encoding.send-window-size': True, 'encoding.scrolling': True}, 0, {'focused': True}, False, 1, (1080, 1920), []] configure event: current size=(499, 316), new size=(495, 305), backing=gtk3.CairoBacking(<cairo.ImageSurface object at 0x00000000253284f0>), iconified=False
- then when we move it, the server processes the configure packet:
_process_configure_window([1, 216, 253, 495, 305, {}, 0, {}, False, 1, (395, 236), ()]) old window geometry: (211, 245, 495, 305) _update_client_geometry: using owner=DesktopManager(1) (setup_done=True) _do_update_client_geometry: allocated 495x305 (from <function WindowModel._update_client_geometry.<locals>.window_size at 0x7f939fa52170>) calc_constrained_size(495, 305, {'base-size': (19, 4), 'increment': (6, 13), 'gravity': 1, 'minimum-size': (194, 55)})=(493, 303) (size_constraints=(194, 55, 32767, 32767)) _do_update_client_geometry: size({'base-size': (19, 4), 'increment': (6, 13), 'gravity': 1, 'minimum-size': (194, 55)})=493x303
and the downward spiral begins.
Turning off the size apply_maxsize_hints
workaround using XPRA_WIN32_GEOMETRY=0
does not help. (flag renamed to XPRA_WIN32_MAX_SIZE_HINT
in r24356)
With r24357:
- on Linux (OK):
apply_geometry_hints({b'min_width': 25, b'min_height': 17, b'base_width': 19, b'base_height': 4, b'width_inc': 6, b'height_inc': 13, b'max_width': 32767, b'max_height': 32764}) geometry=<Gdk.Geometry object at 0x7fa258cfde90 (void at 0x557d7dea1f40)>, \ hints=<flags GDK_HINT_MIN_SIZE | GDK_HINT_MAX_SIZE | GDK_HINT_BASE_SIZE | GDK_HINT_RESIZE_INC of type Gdk.WindowHints>
- on win32 (NOK):
apply_geometry_hints({b'base_width': 19, b'base_height': 4, b'width_inc': 6, b'height_inc': 13}) geometry=<Gdk.Geometry object at 0x0000000025598db0 (void at 0x00000000242ec7b0)>, hints=<flags GDK_HINT_BASE_SIZE | GDK_HINT_RESIZE_INC of type Gdk.WindowHints>
Differences are expected (ie: we can't set the max-size on win32 because then the maximize buttons end up greyed out)
My guess is that this is a GTK3 bug, maybe it is taking into account the window borders or something.
The new window size is smaller by 4x11.
comment:6 Changed 3 years ago by
I thought it might be related to the wayland changes in r23305 (#2243), but using the window geometry gives the same / similar result.
r24377 adds a simple test gtk window script.
- running it on Linux X11, we get exactly the same geometry from the configure event as we get when querying the drawing area, which is also the size that the window originally requested (
499x316
) - all is well:event geometry: (0, 64, 499, 316) drawing area geometry: (0, 64, 499, 316) event geometry: (170, 67, 499, 316) drawing area geometry: (170, 67, 499, 316)
- on win32, we get something else, twice... hence the problem.
event geometry: (37, 37, 547, 394) drawing area geometry: (63, 97, 495, 305) event geometry: (37, 37, 547, 394) drawing area geometry: (63, 97, 495, 305)
- on wayland (via weston), we also get an invalid geometry! The same values as win32, as a "bonus" we also get a completely whacky geometry for the first event:
event geometry: (0, 0, 599, 446) drawing area geometry: (26, 60, 495, 305) event geometry: (0, 0, 547, 394) drawing area geometry: (26, 60, 495, 305)
comment:7 Changed 3 years ago by
comment:8 Changed 3 years ago by
Can we temporarily hardwire the GTK version for the v4.0 branch? Or: Which "most up-to-date" client does not use GTK3? is it "Xpra-Python2-x86_64_3.0.2-r24303.zip" this one?
The problematic values only occur with GTK3, on Wayland and win32.
I am not on Wayland (I think), since I have Ubuntu 16.04.6?
So, why am I affected? Or is it GTK3 AND (Wayland OR WIN32)
?
comment:9 Changed 3 years ago by
Owner: | changed from Antoine Martin to stdedos |
---|---|
Status: | assigned → new |
Fixed in r24380, backport in r24381: GTK3 requires a widget to apply the window size hints correctly.
The test script has also been updated to return the correct values.
@stdedos: there are 4.0 and 3.0.2 mswindows beta builds with this fix here: https://xpra.org/beta/windows.
Please close if that works for you.
comment:10 Changed 3 years ago by
Which "most up-to-date" client does not use GTK3?
The python2 builds use GTK2.
The python3 builds use GTK3.
We have no choice there.
So, why am I affected?
Because your mswindows client uses GTK3:
Xpra GTK3 client version 4.0-r24195 64-bit
Python3 + GTK3 is the new default since version 3.
comment:11 Changed 3 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
3.0.2 has been released with this fix.
There is now a similar ticket for window position: #2475.
comment:12 Changed 3 years ago by
It's interesting to note that Gtk.Window.set_geometry_hints documentation states that: Since 3.20 this argument is ignored and GTK behaves as if None was set.
comment:14 Changed 17 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2457
Do you have the client and server output?
If possible, please attach the
-d geometry
flag to both client and server.