Xpra: Ticket #2762: xpra new-border & window render miscalculations

"Xpra-Python3-x86_64_4.1-r26328\xpra_cmd" attach ssh://user@ip/20 --ssh="plink -ssh -agent" --modal-windows=no --title="@title@ on @hostname@/@server-display@" --opengl=no --bandwidth-limit=6Mbps
2020-05-13 10:32:09,414 Xpra GTK3 client version 4.1-r26328 64-bit
2020-05-13 10:32:09,417  running on Microsoft Windows 10
2020-05-13 10:32:09,531 Warning: failed to import opencv:
2020-05-13 10:32:09,532  No module named 'cv2'
2020-05-13 10:32:09,532  webcam forwarding is disabled
2020-05-13 10:32:11,944 GStreamer version 1.16.2 for Python 3.8.2 64-bit
2020-05-13 10:32:12,771 keyboard layout code 0x409
2020-05-13 10:32:12,772 identified as 'United States - English' : us
2020-05-13 10:32:13,469  keyboard settings: layout=us
2020-05-13 10:32:13,483  desktop size is 4160x1440 with 1 screen:
2020-05-13 10:32:13,486   Default (1100x381 mm - DPI: 96x96) workarea: 4160x1400
2020-05-13 10:32:13,487     Generic PnP Monitor 1600x900 at 0x534 (309x174 mm - DPI: 131x131) workarea: 1600x860
2020-05-13 10:32:13,488     C32JG5x 2560x1440 at 1600x0 (697x392 mm - DPI: 93x93) workarea: 2560x1400
2020-05-13 10:32:18,543 enabled remote logging
2020-05-13 10:32:18,545 Xpra GTK3 X11 server version 3.0.9-r26132 64-bit
2020-05-13 10:32:18,545  running on Linux Ubuntu 16.04 xenial

There is a workaround: Maximized > Windowed > Maximized

I would also note that there are ways to add trinkets in native Windows toolbars (I don't know them, but there are others that do it) - I guess though it might be out of your scope or GTK's



Wed, 13 May 2020 07:55:49 GMT - stdedos: attachment set


Wed, 13 May 2020 07:56:39 GMT - stdedos: description changed


Wed, 13 May 2020 08:11:41 GMT - stdedos:

There is also window-size miscalculation:

ShareX can take size hints about windows and "random elements" and auto-draw their bounding box. Said hints are off too.


Wed, 13 May 2020 08:13:06 GMT - stdedos: attachment set


Wed, 13 May 2020 08:15:54 GMT - stdedos: attachment set


Wed, 13 May 2020 08:25:45 GMT - stdedos:

... and #2457 has re-surfaced


Wed, 13 May 2020 09:33:20 GMT - stdedos: description changed


Wed, 13 May 2020 13:40:34 GMT - stdedos:

.. and maybe some part of #2455 is still active (but I haven't tested it)


Wed, 13 May 2020 14:59:27 GMT - Antoine Martin: owner changed

New border takes too much of screen estate and looks ugly.

By border, you mean title bar, right? (that's #2539) It is a little bit bigger than the normal title bar... That's a GTK design decision. I found some links to change this:

Can it be disabled?

As of r26344: XPRA_CUSTOM_TITLE_BAR=0

(The menu might be useful, but at this time I don't see it)

You don't see the menu? Or its purpose? The "window info" is extremely useful for debugging window geometry and state issues. It can also be shown using ShortcutKey+Shift+F5.

There is a workaround: Maximized > Windowed > Maximized

What is this window? Is it easy to reproduce?

I would also note that there are ways to add trinkets in native Windows toolbars (I don't know them, but there are others that do it) - I guess though it might be out of your scope or GTK's

Do you mean this: Custom Window Frame Using DWM?

Moving away from GTK is in the roadmap, so this may still happen.

There is also window-size miscalculation:

GTK makes this almost impossible to fix... (hence the point above about moving away)

ShareX can take size hints about windows and "random elements" and auto-draw their bounding box. Said hints are off too.

I don't understand.


Wed, 13 May 2020 15:57:06 GMT - stdedos:

Replying to Antoine Martin:

New border takes too much of screen estate and looks ugly.

By border, you mean title bar, right? (that's #2539)

Yeah - I don't know why my head decides to cross-wire different terms 😕

I would also note that there are ways to add trinkets in native Windows toolbars (I don't know them, but there are others that do it) - I guess though it might be out of your scope or GTK's

Do you mean this: Custom Window Frame Using DWM?

Moving away from GTK is in the roadmap, so this may still happen.

Can't wait :-D

ShareX can take size hints about windows and "random elements" and auto-draw their bounding box. Said hints are off too.

I don't understand.

It might make it more obvious if you see it yourself:


(The menu might be useful, but at this time I don't see it)

You don't see the menu? Or its purpose? The "window info" is extremely useful for debugging window geometry and state issues. It can also be shown using ShortcutKey+Shift+F5.

More like the day-to-day purpose, given that you set it active-by-default. More explicitly, the cost/benefit, given that:

It is a little bit bigger than the normal title bar... That's a GTK design decision. I found some links to change this:

I'd prefer it fixed, though I can certainly work with the disable option - thank you for that :-D

There is a workaround: Maximized > Windowed > Maximized

What is this window? Is it easy to reproduce?

LibreOffice, Sublime, gnome-terminal. Pick your poison.

There is also window-size miscalculation:

GTK makes this almost impossible to fix... (hence the point above about moving away)

Thank you for the env-disable again :-D


Sun, 17 May 2020 17:17:25 GMT - Antoine Martin: attachment set

"win32" GTK_THEME


Sun, 17 May 2020 17:44:53 GMT - Antoine Martin:

Merged a generic file based CSS override mechanism in r26368 and verified that the CSS settings were being applied to the download progress bar (#2678). Then I tried all the "solutions" from the links in comment:6 and none of them made any difference at all to the theme used on mswindows. But this put me on the right track: How to change the window title font color in the adwaita theme?, using GTK_DEBUG=interactive xpra_cmd ... I found that I could just use the GTK_THEME=win32 and get a much smaller headerbar from this theme: (the pancake button is still a little bit too big) Maybe there is a theme somewhere that looks more like a native win10 theme and has a thin header bar? This one will do for now.

@stdedos: I'm going to look at the sizing issue next.


Sun, 17 May 2020 18:01:27 GMT - stdedos:

Replying to Antoine Martin:

Maybe there is a theme somewhere that looks more like a native win10 theme and has a thin header bar? This one will do for now.

Definitelly will do. I mean, the header bar size is a bit off, but at least now it is just "eating up screen real estate". It can be classified as a nitpick, and you do have the env-workaround in there. I am all for calling this off and let you work on "real" issues instead, ...

@stdedos: I'm going to look at the sizing issue next.

... given that the size is fixed, and ...

... and #2457 has re-surfaced

... remember that I still may call you out on this one re-appearing sometime between ~r26128 and r26328. I wasn't updating for a long time, since I only saw Win32 shadow/proxy changes (and I don't care about them).


Mon, 18 May 2020 08:15:34 GMT - Antoine Martin: owner, status changed

r26390 adds the b00merang windows-10 theme, which looks good and is only marginally bigger than the default OS theme.

Needs packaging: #2767


Tue, 19 May 2020 08:42:43 GMT - stdedos:

Replying to stdedos:

(The menu might be useful, but at this time I don't see it)

You don't see the menu? Or its purpose? The "window info" is extremely useful for debugging window geometry and state issues. It can also be shown using ShortcutKey+Shift+F5.

Which ShortcutKey? Cmd/Ctrl?

Ctrl+Shift+F5 does not seem to work 😕


Tue, 19 May 2020 08:50:47 GMT - stdedos:

Border calculation:

Re-attaching from r26160 / ~r26346 ; XPRA_CUSTOM_TITLE_BAR=0 / r26385:

From background to foreground: Windows Desktop, Libre Office, Gnome-Terminal

It takes to re-maximizations (for Libre Office) to properly maximize, and gnome-terminal absolutely refuses to follow suit:


Tue, 19 May 2020 08:51:04 GMT - stdedos: attachment set


Tue, 19 May 2020 08:51:18 GMT - stdedos: attachment set


Tue, 19 May 2020 08:58:34 GMT - stdedos: attachment set


Tue, 19 May 2020 13:04:56 GMT - Antoine Martin: owner, status changed

Ctrl+Shift+F5 does not seem to work 😕 Which ShortcutKey? Cmd / Ctrl?

--shortcut-modifiers=auto should be using Meta+Shift on mswindows. You can change it, ie: --shortcut-modifiers=Control+Shift.

Border calculation:

What am I looking at? Is the window geometry wrong? It looks OK to me (but then again, I have no idea what this is..)

(..) From background to foreground: Windows Desktop, Libre Office, Gnome-Terminal

I have no idea what I am supposed to be seeing here!


Tue, 19 May 2020 13:31:21 GMT - stdedos:

Replying to Antoine Martin:

Ctrl+Shift+F5 does not seem to work 😕 Which ShortcutKey? Cmd / Ctrl?

--shortcut-modifiers=auto should be using Meta+Shift on mswindows. You can change it, ie: --shortcut-modifiers=Control+Shift.

Alt+Shift it is (rather Shift+Alt, I think the other way around registers a language change only)

Border calculation:

What am I looking at? Is the window geometry wrong? It looks OK to me (but then again, I have no idea what this is..)

This is the "Paste Special" functionality window in LibreOffice (Ctrl+Shift+V). It is missing the buttons in the bottom of the window (they are somewhat visible though)

(..) From background to foreground: Windows Desktop, Libre Office, Gnome-Terminal

I have no idea what I am supposed to be seeing here!

You are looking at 2 maximized windows. At least that is what the "Restore" button (the one next to the Red X i.e. close button) signifies


Mon, 25 May 2020 07:59:47 GMT - stdedos:

Xpra-Python3-x86_64_4.1-r26463:

Nice one on the theme. Although, the White Titlebar makes it feel like "unfocused".

If you could steal the tint of Windows (even just once during initialization), and color toolbar with it while a window is focused, would help with the UX of what is the state of the windows.

Nice touch on stowing the menu on the icon itself :-D


Mon, 25 May 2020 08:00:32 GMT - stdedos: attachment set


Mon, 25 May 2020 08:43:54 GMT - stdedos: owner changed

On the other attached photo:


Mon, 25 May 2020 08:44:10 GMT - stdedos: attachment set


Mon, 25 May 2020 10:43:44 GMT - stdedos: attachment set


Mon, 25 May 2020 10:43:59 GMT - stdedos:

Now even random menu items are off-set


Mon, 25 May 2020 13:50:36 GMT - stdedos:

Also also, Chromium windows without system titlebars, somehow have "locked" in a perma-click-drag state from their titlebar, and move downwards-only, the further down the screen the mouse pointer goes. They don't go upwards though.

I guess I'll resort again to using the env workaround tomorrow.


Tue, 26 May 2020 04:22:12 GMT - Antoine Martin: owner, status changed

Alt+Shift it is (rather Shift+Alt, I think the other way around registers a language change only)

Ah. As you found out, xpra does not care about the order: Alt+Shift == Shift+Alt.

If you could steal the tint of Windows

Might be possible, it's not clear which API is the right one to use:

Now even random menu items are off-set

Yes, that's the geometry difference between CSD and regular windows. I hope I can figure out the correct offset to use, somehow.


Tue, 26 May 2020 15:36:12 GMT - stdedos:

Replying to Antoine Martin:

Ctrl+Shift+F5 does not seem to work 😕 Which ShortcutKey? Cmd / Ctrl?

--shortcut-modifiers=auto should be using Meta+Shift on mswindows. You can change it, ie: --shortcut-modifiers=Control+Shift.

btw, are all the available shortcuts collected/listed somewhere?

If not, would you add something along those lines:

(my mockup is not perfect, but I hope it conveys the idea)

You can assign prefix+? to it (the /? key, not necessarily the ? if it is harder to map because of "Shift" weirdness), and a tray-entry


Tue, 26 May 2020 15:36:26 GMT - stdedos: attachment set


Wed, 27 May 2020 08:26:49 GMT - Antoine Martin:

Matching the theme:

Result in r26477.

More css links:

Caveat: we don't change the theme on-the-fly, re-connecting is necessary.

Next: geometry issues.

btw, are all the available shortcuts collected/listed somewhere?

Please don't hijack this ticket. (showing the shortcuts would be possible, editing and saving would be harder)


Wed, 27 May 2020 08:43:40 GMT - stdedos:

Replying to Antoine Martin:

Matching the theme:

Result in r26477.

Caveat: we don't change the theme on-the-fly, re-connecting is necessary.

All is good :-D As long as we also don't end up with windows that look like perma-unfocused.

Next: geometry issues.

Fingers crossed

btw, are all the available shortcuts collected/listed somewhere?

Please don't hijack this ticket. (showing the shortcuts would be possible, editing and saving would be harder)

Apologies, generic discussion and tickets are weird - and I don't want to open tickets for whatever pops in my head, if there is no way you'd even consider it. #2779


Wed, 27 May 2020 15:54:53 GMT - Antoine Martin:

And now, finally, on to the geometry issue. I swear I saw it using something a lot easier than libreoffice calc, it was so obvious that I didn't make a note of it... And now I can't remember what it was.

On the plus side, I can reproduce the problem on Linux, which will make it much easier to work on.

Anyway. Here's the paste window:

setup() hints={'position': (0, 0), 'base-size': (0, 0), 'gravity': 1, 'minimum-size': (283, 469), 'maximum-size': (283, 469)} size=283x469
client  38 @57.129 modified hints for max window size (32767, 32767): \
    {b'max_width': 283, b'max_height': 469, b'min_width': 283, b'min_height': 469, b'base_width': 0, b'base_height': 0} (rw=0, rh=0) -> max=283x469
client  38 @57.147 configure event: current size=(283, 469), new size=(231, 376), backing=gtk3.CairoBacking(<cairo.ImageSurface object at 0x0000000022f45a10>), iconified=False

We request 283x469, but the configure event comes in for 231x376!? Then we tell the server, which correctly refuses this invalid size and sends the correct size to the client again. The client tries again, comes up with the same (wrong) value again and we stop there because the geometry is unchanged on the client.

The new "geometry size constraints" tool I've just added to the toolbox (r26480) doesn't reproduce the problem?

python3 ./xpra/client/gtk_base/example/window_geometry_hints.py  283 469  283 469  283 469  0 0

Wed, 27 May 2020 17:10:57 GMT - Antoine Martin:

The new "geometry size constraints" tool does reproduce the problem (just remember to enable "headerbar"), and this is now confirmed as a GTK3 bug: GTK ignores the decorations and grab area that it adds to the window. So when we request a size, a large chunk of it gets eaten away by those (partially hidden) widgets, and we get something else, much smaller.

The only way I can get a window size that approaches the size we actually want is to:

A better way might be:

(could also probe this delta value during startup, so we can pre-adjust the size-constraints and get closer to the correct value on the first try)

What a mess!


Thu, 28 May 2020 07:16:03 GMT - stdedos:

Replying to Antoine Martin:

Matching the theme:

Result in r26477.

Caveat: we don't change the theme on-the-fly, re-connecting is necessary.

Any idea why did you set rgba and not just rgb? Toolbar feels weird having a transparency-by-default.


Thu, 28 May 2020 07:26:42 GMT - stdedos:

A couple of comments for this (apart from the transparency):

It almost looks like native toolbar!

and, I am not going to complain, but ...


Thu, 28 May 2020 07:26:53 GMT - stdedos: attachment set


Thu, 28 May 2020 08:55:03 GMT - Antoine Martin: owner, status changed

Any idea why did you set rgba and not just rgb? Toolbar feels weird having a transparency-by-default.

Fixed in r26487. (FWIW, I quite liked it, can be re-enabled with XPRA_TITLEBAR_TRANSPARENCY=1)

However, why doesn't the window fit now? 😕

AFAIK, it never did with the titlebar enabled? (see comment:24)

The top-right window buttons look very very weird

How so?


Thu, 28 May 2020 09:02:00 GMT - stdedos: owner changed

Replying to Antoine Martin:

Any idea why did you set rgba and not just rgb? Toolbar feels weird having a transparency-by-default.

Fixed in r26487. (FWIW, I quite liked it, can be re-enabled with XPRA_TITLEBAR_TRANSPARENCY=1)

I may or may not get used to the idea - the statement/question was more like "It's not native Windows UI/Where did it come from?"

However, why doesn't the window fit now? 😕

AFAIK, it never did with the titlebar enabled? (see comment:24)

Yes, but now the titlebar is shortened - even more than the original Windows 10 one! How can this be? Or is it so that: If GDK draws it, then it subtracts its size from the requested draw area (and never compensates for it)?

The top-right window buttons look very very weird

How so?


Fri, 29 May 2020 06:30:49 GMT - stdedos:

Also related to this, windows with size-increments are not maximized properly (i.e. famous, gnome-terminal).


Mon, 13 Jul 2020 09:53:12 GMT - stdedos:

Now I have the inverse problem of comment:2:

wid=483
title=Open Project on @/:2
override-redirect=False
state=skip-taskbar
attributes=
focused=False
buttons=none
gravity=NorthWest
content-type=unknown
pixel-depth=24
alpha=False
opengl=False
geometry=1021x448 at 2708,414
outer-geometry=1021x448 at 2708,373
inner-geometry=1021x448 at 2708,414
offsets=none
frame-extents=8, 8, 31, 8
max-size=32767, 32767
size-constraints=position : (2364, 640)
minimum-size : (442, 87)
size=1021, 448
render-size=1021, 448
backing-offsets=0, 0, 0, 0

i.e. this is fixed

and this, while it bothers me, it may not be as consequential It is clear in my screenshots, however, that it still happens.


Mon, 13 Jul 2020 10:35:15 GMT - stdedos: attachment set


Tue, 21 Jul 2020 15:44:26 GMT - Antoine Martin: owner, priority, status changed; milestone set

As per ticket:2539#comment:21, the headerbar is now disabled on win32 by default. As of r27010 we also don't use it for any windows that have size-constraints.

Ideally, we would find a way to calculate the offset created by the headerbar, but I see no way of doing that without also showing the window - by which point it is already too late...


Tue, 21 Jul 2020 16:00:23 GMT - stdedos:

Replying to Antoine Martin:

Ideally, we would find a way to calculate the offset created by the headerbar, but I see no way of doing that without also showing the window - by which point it is already too late...

Can't you do that after you draw, and then enforce the constraints?

I know it will look weird for a split-second, but maybe it's good enough for now.

Or, can't you draw the window inside an imaginary place (tm), measure it, constrain it, and then make it appear?


Tue, 21 Jul 2020 16:53:11 GMT - Antoine Martin: status changed; resolution set

Can't you do that after you draw, and then enforce the constraints?

Difficult without also going through a whole round of client-server resizing sync, potentially creating an endless resizing loop.

Or, can't you draw the window inside an imaginary place (tm), measure it, constrain it, and then make it appear?

That's what I mean by no way of doing that without also showing the window.

I'm going to close this ticket, and we can re-visit in #2824.


Sat, 23 Jan 2021 06:00:04 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2762