"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
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.
... and #2457 has re-surfaced
.. and maybe some part of #2455 is still active (but I haven't tested it)
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.
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:
PrtScr
(hopefully all is well and ShareX has hooked itself on the button)
Q
(Multi-region capture, https://getsharex.com/docs/region-capture#region-capture)
(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
"win32" GTK_THEME
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.
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).
r26390 adds the b00merang windows-10 theme, which looks good and is only marginally bigger than the default OS theme.
Needs packaging: #2767
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 😕
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:
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!
Replying to Antoine Martin:
Ctrl+Shift+F5 does not seem to work 😕 Which
ShortcutKey
?Cmd
/Ctrl
?
--shortcut-modifiers=auto
should be usingMeta+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
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
On the other attached photo:
Now even random menu items are off-set
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.
Alt+Shift
it is (ratherShift+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:
TMT_WINDOWFRAME
: The color of the frame around a window.
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.
Replying to Antoine Martin:
Ctrl+Shift+F5 does not seem to work 😕 Which
ShortcutKey
?Cmd
/Ctrl
?
--shortcut-modifiers=auto
should be usingMeta+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
Matching the theme:
DwmGetColorizationParameters
to get the color of the window frame
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)
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
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
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!
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.
A couple of comments for this (apart from the transparency):
It almost looks like native toolbar!
and, I am not going to complain, but ...
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?
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?
Also related to this, windows with size-increments are not maximized properly (i.e. famous, gnome-terminal).
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
and this, while it bothers me, it may not be as consequential It is clear in my screenshots, however, that it still happens.
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...
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?
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.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2762