xpra new-border & window render miscalculations

[totaam]

Issue migrated from trac ticket # 2762

component: client | priority: minor | resolution: worksforme

2020-05-13 08:55:37: stdedos created the issue

---

"Xpra-Python3-x86_64_4.1-[r26328](../commit/af814d4919cd7067a4a403c51d2c8a4eb34a5774)\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](../commit/af814d4919cd7067a4a403c51d2c8a4eb34a5774) 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-26132 64-bit
2020-05-13 10:32:18,545  running on Linux Ubuntu 16.04 xenial

• New border takes too much of screen estate and looks ugly. Can it be disabled? (The menu might be useful, but at this time I don't see it)

• This weirdness:
  [[Image(xpra-new-border-rendering.png)]]
  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

[totaam]

2020-05-13 08:55:50: stdedos uploaded file xpra-new-border-rendering.png (52.1 KiB)

[totaam]

2020-05-13 08:56:39: stdedos edited the issue description

[totaam]

2020-05-13 09:11:41: stdedos commented

---

There is also window-size miscalculation:
[[Image(Xpra-2762-_cmd_2020-05-13_11-14-44.png)]]

ShareX can take size hints about windows and "random elements" and auto-draw their bounding box. Said hints are off too.
[[Image(xpra-2762-ShareX_2020-05-13_11-09-48.png)]]

[totaam]

2020-05-13 09:13:07: stdedos uploaded file xpra-2762-ShareX_2020-05-13_11-09-48.png (53.1 KiB)

[totaam]

2020-05-13 09:15:54: stdedos uploaded file Xpra-2762-_cmd_2020-05-13_11-14-44.png (15.8 KiB)

[totaam]

2020-05-13 09:25:45: stdedos commented

---

... and #2457 has re-surfaced

[totaam]

2020-05-13 14:40:34: stdedos commented

---

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

[totaam]

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:

• How to change the titlebar height in standard GTK apps and those with headerbars/CSDs on Gnome 3.20
• Decrease height of title bar of apps without switching theme on Ubuntu 18.04

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.

[totaam]

2020-05-13 16:57:07: stdedos commented

---

Replying to [comment:6 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:

• Download & Run ShareX (https://github.com/ShareX/ShareX/releases/tag/v13.1.0)
• Start taking a screenshot with PrtScr (hopefully all is well and ShareX has hooked itself on the button)
• Press Q (Multi-region capture, https://getsharex.com/docs/region-capture#region-capture)
• Point-click on one of xpra's Windows, point-click at a Chrome window, and compare the bounding box that ShareX is drawing for each selection (hovering should work too, but it may need to be configured)

---

(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 makes enough "unnecessary UI changes"
• It's bringing a lot of issues with it too (I am assuming you saw them yourself already, given your comments)
• For something you would aspire would never happen (I guess every developer sees/imagines its child as bug free)

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

• How to change the titlebar height in standard GTK apps and those with headerbars/CSDs on Gnome 3.20
• Decrease height of title bar of apps without switching theme on Ubuntu 18.04

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

[totaam]

2020-05-17 18:17:26: antoine uploaded file win32-theme.png (34.7 KiB)

"win32" GTK_THEME

[totaam]

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: win32-theme.png above
(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.

[totaam]

2020-05-17 19:01:27: stdedos commented

---

Replying to [comment:8 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 ~26128 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).

[totaam]

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

Needs packaging: #2767

[totaam]

2020-05-19 09:42:44: stdedos commented

---

Replying to [comment:7 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 😕

[totaam]

2020-05-19 09:50:48: stdedos commented

---

Border calculation:
[[Image(Xpra-2762_cmd_2020-05-19_11-44-45.png)]]

Re-attaching from r26160 / ~r26346 ; XPRA_CUSTOM_TITLE_BAR=0 / r26385:
[[Image(Xpra-2762_cmd_2020-05-19_11-47-07.png)]]

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:
[[Image(Xpra-2762_cmd_2020-05-19_11-55-26.png)]]

[totaam]

2020-05-19 09:51:05: stdedos uploaded file Xpra-2762_cmd_2020-05-19_11-44-45.png (69.5 KiB)

[totaam]

2020-05-19 09:51:18: stdedos uploaded file Xpra-2762_cmd_2020-05-19_11-47-07.png (59.3 KiB)

[totaam]

2020-05-19 09:58:34: stdedos uploaded file Xpra-2762_cmd_2020-05-19_11-55-26.png (752.3 KiB)

[totaam]

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!

[totaam]

2020-05-19 14:31:22: stdedos commented

---

Replying to [comment:13 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

[totaam]

2020-05-25 08:59:47: stdedos commented

---

Xpra-Python3-x86_64_4.1-26463:
[[Image(xpra-2762_2020-05-25_10-54-23.png)]]

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

[totaam]

2020-05-25 09:00:32: stdedos uploaded file xpra-2762_2020-05-25_10-54-23.png (60.1 KiB)

[totaam]

2020-05-25 09:43:55: stdedos commented

---

On the other attached photo:

• Sublime came in in "Restored" mode - un-maximized, as you call it (maximizing worked, as shown here)

• gnome-terminal came in this state (appears as Maximized), and refuses to be properly maximized (on click-drag maximization, it keeps moving down and left until it jumps to my next monitor, disappears, and become ~10 lines in height)
• LibreOffice came in like this: Maximized, but some part of its viewport is blank. Re-maximizing fixes that.

[totaam]

2020-05-25 09:44:11: stdedos uploaded file xpra-2762-attach.png (269.8 KiB)

[totaam]

2020-05-25 11:43:44: stdedos uploaded file xpra-2762-cmd_2020-05-25_13-40-02.png (37.7 KiB)

[totaam]

2020-05-25 11:44:00: stdedos commented

---

Now even random menu items are off-set
[[Image(xpra-2762-cmd_2020-05-25_13-40-02.png)]]

[totaam]

2020-05-25 14:50:36: stdedos commented

---

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.

[totaam]

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:

• Visual Styles Reference
• GetCurrentThemeName
• GetThemeColor
• GetThemeSysColorBrush: TMT_WINDOWFRAME : The color of the frame around a window.
• How do I retrieve the theme colour of Windows?: DwmGetColorizationColor
• Get Modern UI theme colour manually

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.

[totaam]

2020-05-26 16:36:13: stdedos commented

---

Replying to [comment:13 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:
[[Image(xpra-example-shortcuts.png)]]

(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

[totaam]

2020-05-26 16:36:27: stdedos uploaded file xpra-example-shortcuts.png (6.8 KiB)

[totaam]

Matching the theme:

• used the totally undocumented DwmGetColorizationParameters to get the color of the window frame
• spend ages trying to figure out what CSS attributes to use for modifying the gtk headerbar (undocumented)
• add heuristics so we don't end up with invisible title color (ie: grey on grey) - not sure how mswindows does it

Result in r26477.

More css links:

• gtk3 GtkWindow title bar color
• Gnome 3.2 changing title bar color of the active window?

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)

[totaam]

2020-05-27 09:43:40: stdedos commented

---

Replying to [comment:21 Antoine Martin]:

Matching the theme:

• used the totally undocumented DwmGetColorizationParameters to get the color of the window frame
• spend ages trying to figure out what CSS attributes to use for modifying the gtk headerbar (undocumented)
• add heuristics so we don't end up with invisible title color (ie: grey on grey) - not sure how mswindows does it

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

[totaam]

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

[totaam]

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:

• not set the window size constraints at all (ouch)
• set the drawing area's size_request
• once we receive the first configure-event signal, remove the size request...

A better way might be:

• set the size constraints
• wait for the map-event and adjust the size-constraints based on the delta
  (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!

[totaam]

2020-05-28 08:16:03: stdedos commented

---

Replying to [comment:21 Antoine Martin]:

Matching the theme:

• used the totally undocumented DwmGetColorizationParameters to get the color of the window frame
• spend ages trying to figure out what CSS attributes to use for modifying the gtk headerbar (undocumented)
• add heuristics so we don't end up with invisible title color (ie: grey on grey) - not sure how mswindows does it

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.

[totaam]

2020-05-28 08:26:42: stdedos commented

---

A couple of comments for this (apart from the transparency):
[[Image(xpra-2762_cmd_2020-05-28_10-20-35.png)]]

It almost looks like native toolbar!

• However, why doesn't the window fit now? 😕
• The top-right window buttons look very very weird

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

• Your toolbar is smaller than the official one :-D

[totaam]

2020-05-28 08:26:54: stdedos uploaded file xpra-2762_cmd_2020-05-28_10-20-35.png (79.3 KiB)

[totaam]

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?

[totaam]

2020-05-28 10:02:01: stdedos commented

---

Replying to [comment:27 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?

• Minimized button has two horizontal likes

• Restore button (un-maximize) has two squares inside each other, whereas the "official" icon is two similar squares with an +top,+right offset of each other ("reading" the icon left-to-right)
• Close button is more like left-half X and right-half calligraphy-typed K merged, instead of a "pure" X

[totaam]

2020-05-29 07:30:49: stdedos commented

---

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

[totaam]

2020-07-13 10:53:12: stdedos commented

---

Now I have the inverse problem of comment:2:
[[Image(Xpra-2762_cmd_2020-07-13_12-44-16.png)]]

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*
[[Image(Xpra-2762-_cmd_2020-05-13_11-14-44.png)]]

-and this, while it bothers me, it may not be as consequential*
[[Image(xpra-2762-ShareX_2020-05-13_11-09-48.png)]]
It is clear in my screenshots, however, that it still happens.

[totaam]

2020-07-13 11:35:15: stdedos uploaded file Xpra-2762_cmd_2020-07-13_12-44-16.png (22.1 KiB)

[totaam]

As per #2539 (comment), 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...

[totaam]

2020-07-21 17:00:24: stdedos commented

---

Replying to [comment:31 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?

[totaam]

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.