xpra icon
Bug tracker and wiki

Opened 7 months ago

Closed 5 months ago

#2762 closed defect (worksforme)

xpra new-border & window render miscalculations

Reported by: stdedos Owned by: Antoine Martin
Priority: minor Milestone: 4.1
Component: client Version: 4.0.x
Keywords: Cc:

Description (last modified by stdedos)

"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
  • 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:


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

Attachments (13)

xpra-new-border-rendering.png (52.1 KB) - added by stdedos 7 months ago.
xpra-2762-ShareX_2020-05-13_11-09-48.png (53.1 KB) - added by stdedos 7 months ago.
Xpra-2762-_cmd_2020-05-13_11-14-44.png (15.8 KB) - added by stdedos 7 months ago.
win32-theme.png (34.7 KB) - added by Antoine Martin 7 months ago.
"win32" GTK_THEME
Xpra-2762_cmd_2020-05-19_11-44-45.png (69.5 KB) - added by stdedos 7 months ago.
Xpra-2762_cmd_2020-05-19_11-47-07.png (59.3 KB) - added by stdedos 7 months ago.
Xpra-2762_cmd_2020-05-19_11-55-26.png (752.3 KB) - added by stdedos 7 months ago.
xpra-2762_2020-05-25_10-54-23.png (60.1 KB) - added by stdedos 6 months ago.
xpra-2762-attach.png (269.8 KB) - added by stdedos 6 months ago.
xpra-2762-cmd_2020-05-25_13-40-02.png (37.7 KB) - added by stdedos 6 months ago.
xpra-example-shortcuts.png (6.8 KB) - added by stdedos 6 months ago.
xpra-2762_cmd_2020-05-28_10-20-35.png (79.3 KB) - added by stdedos 6 months ago.
Xpra-2762_cmd_2020-07-13_12-44-16.png (22.1 KB) - added by stdedos 5 months ago.

Download all attachments as: .zip

Change History (46)

Changed 7 months ago by stdedos

comment:1 Changed 7 months ago by stdedos

Description: modified (diff)

comment:2 Changed 7 months ago by 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.

Last edited 7 months ago by stdedos (previous) (diff)

Changed 7 months ago by stdedos

Changed 7 months ago by stdedos

comment:3 Changed 7 months ago by stdedos

... and #2457 has re-surfaced

comment:4 Changed 7 months ago by stdedos

Description: modified (diff)

comment:5 Changed 7 months ago by stdedos

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

comment:6 Changed 7 months ago by Antoine Martin

Owner: changed from Antoine Martin to stdedos

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.

comment:7 in reply to:  6 ; Changed 7 months ago by 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 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:

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

Last edited 7 months ago by stdedos (previous) (diff)

Changed 7 months ago by Antoine Martin

Attachment: win32-theme.png added

"win32" GTK_THEME

comment:8 Changed 7 months ago by 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:
"win32" GTK_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.

comment:9 in reply to:  8 Changed 7 months ago by 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).

comment:10 Changed 7 months ago by Antoine Martin

Owner: changed from stdedos to Antoine Martin
Status: newassigned

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

Needs packaging: #2767

Last edited 7 months ago by Antoine Martin (previous) (diff)

comment:11 in reply to:  7 Changed 7 months ago by 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 😕

comment:12 Changed 7 months ago by 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:

Last edited 7 months ago by stdedos (previous) (diff)

Changed 7 months ago by stdedos

Changed 7 months ago by stdedos

Changed 7 months ago by stdedos

comment:13 Changed 7 months ago by Antoine Martin

Owner: changed from Antoine Martin to stdedos
Status: assignednew

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!

comment:14 in reply to:  13 Changed 7 months ago by 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

comment:15 Changed 6 months ago by 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

Changed 6 months ago by stdedos

comment:16 Changed 6 months ago by stdedos

Owner: changed from stdedos to Antoine Martin

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.

Changed 6 months ago by stdedos

Attachment: xpra-2762-attach.png added

Changed 6 months ago by stdedos

comment:17 Changed 6 months ago by stdedos

Now even random menu items are off-set

Last edited 6 months ago by stdedos (previous) (diff)

comment:18 Changed 6 months ago by 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.

comment:19 Changed 6 months ago by Antoine Martin

Owner: changed from Antoine Martin to Antoine Martin
Status: newassigned

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.

comment:20 in reply to:  13 Changed 6 months ago by 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

Changed 6 months ago by stdedos

Attachment: xpra-example-shortcuts.png added

comment:21 Changed 6 months ago by 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.

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)

Last edited 6 months ago by totaamwin32 (previous) (diff)

comment:22 in reply to:  21 Changed 6 months ago by stdedos

Replying to 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

comment:23 Changed 6 months ago by 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

comment:24 Changed 6 months ago by 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:

  • 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!

comment:25 in reply to:  21 Changed 6 months ago by stdedos

Replying to 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.

comment:26 Changed 6 months ago by stdedos

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

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

Changed 6 months ago by stdedos

comment:27 Changed 6 months ago by Antoine Martin

Owner: changed from Antoine Martin to stdedos
Status: assignednew

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?

comment:28 in reply to:  27 Changed 6 months ago by stdedos

Owner: changed from stdedos to Antoine Martin

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?

  • 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

comment:29 Changed 6 months ago by stdedos

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

comment:30 Changed 5 months ago by 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.

Last edited 5 months ago by Antoine Martin (previous) (diff)

Changed 5 months ago by stdedos

comment:31 Changed 5 months ago by Antoine Martin

Milestone: 4.1
Owner: changed from Antoine Martin to Antoine Martin
Priority: majorminor
Status: newassigned

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...

comment:32 in reply to:  31 Changed 5 months ago by 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?

comment:33 Changed 5 months ago by Antoine Martin

Resolution: worksforme
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.