Xpra: Ticket #2539: use header bar for window controls

As in the example here: browser/xpra/trunk/src/xpra/client/gtk_base/example/header_bar.py, we can add our own window widgets to the header bar without changing its geometry. Either using a pancake menu or a few buttons. Things we can do with this:



Thu, 02 Jan 2020 14:32:20 GMT - Antoine Martin: status, description changed


Thu, 02 Jan 2020 21:47:36 GMT - Antoine Martin: milestone changed

This is going to cause more problems with CSD, window geometry 'app-paintable' flag, etc.. Best to wait for the next release?


Sat, 09 May 2020 04:42:57 GMT - Antoine Martin: priority changed

Could be very useful, raising.


Mon, 11 May 2020 15:54:14 GMT - Antoine Martin: attachment set

strip the client window class to the bare minimum to show pixels


Mon, 11 May 2020 16:24:19 GMT - Antoine Martin: attachment set

reproduce the bug using a fake client


Tue, 12 May 2020 04:06:25 GMT - Antoine Martin: attachment set

strip even more


Tue, 12 May 2020 05:21:06 GMT - Antoine Martin:

Doh, turns out that we need to call Gtk.Widget.show to make this work.

r26319 adds a basic menu, requires XPRA_WINDOW_MENU=1 to show it.

Also needed r26314 for better window geometry handling.

TODO:


Tue, 12 May 2020 13:54:43 GMT - Antoine Martin:

Improvements:


Tue, 12 May 2020 15:27:10 GMT - Antoine Martin: attachment set

pancake menu shown on an xterm


Tue, 12 May 2020 15:27:30 GMT - Antoine Martin: attachment set

window info for xterm


Tue, 12 May 2020 15:28:34 GMT - Antoine Martin:

The pancake menu: pancake menu shown on an xterm

And the window info for this xterm: window info for xterm


Tue, 19 May 2020 05:45:57 GMT - Antoine Martin: priority changed

More details about regressions in #2762.

We had lost transparency support, r26403 restores that.

New regression on Linux: non-transparent windows just don't work any more (needs --opengl=force to trigger opengl on all windows to see it with xterm):

2020-05-19 11:58:51,839 glXMakeCurrent: xid=0x3a0510d, context=<OpenGL.raw.GLX._types.LP_struct___GLXcontextRec object at 0x7fffdc33f050>
2020-05-19 11:58:51,840 XError: <class 'Exception'>, glXMakeCurrent failed
Traceback (most recent call last):
  File "/usr/lib64/python3.7/site-packages/xpra/platform/xposix/gl_context.py", line 69, in __enter__
    raise Exception("glXMakeCurrent failed")
Exception: glXMakeCurrent failed

Looks like the visual doesn't match the one we requested?


Fri, 22 May 2020 10:12:46 GMT - Antoine Martin:

More UI improvements: r26444 + r26445 + r26446.

Added some debug and found no difference between the transparent window and non-transparent ones, in both cases:

The map-state changes, it starts as 1 / 0 (IsUnviewable / IsUnmapped) then moves to Viewable 2 / 2.

The fix is in r26449: I'm not sure why but we have to be very careful on which widget we set the visual: even though the GTK window with a header bar already uses transparency, we can't ask for an RGBA visual... because that breaks. But we do have to ask for one to use transparency, and we do have to do the same thing for the drawing area widget.


Fri, 22 May 2020 14:18:57 GMT - Antoine Martin: status changed; resolution set

r26452: adds a "fullscreen" menu item and greys out "maximize" if it can't be used

This will do for now. Works OK on Linux and Windows - not available on MacOS.


Mon, 25 May 2020 10:42:04 GMT - stdedos:

Can you add "Always On Top" boolean?

If it makes any difference whether it is server-side or client-side set, both?

Is the "modal" a separate option, or is it an Attribute?


Tue, 26 May 2020 07:29:16 GMT - Antoine Martin:

Can you add "Always On Top" boolean?

Done in r26468. Beware that we can't add too many entries to this menu, or it will get messy.

If it makes any difference whether it is server-side or client-side set, both?

The client will honour whatever setting applications request server-side, the client menu entry just provides an override.

Is the "modal" a separate option, or is it an Attribute?

"modal" is separate:

Modal would also be complicated by the fact that we have the --modal-windows=yes|no option. "Modal" normally keeps the window on top of other windows from the same PID (ie: all windows forwarded from the same xpra session), not other applications.


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

I meant to add the "Always On Top" boolean on the Windows Information window, not necessarily as a client-toggleable option :-D

But don't take it out 😂. However:


Thu, 28 May 2020 07:35:39 GMT - stdedos: attachment set


Thu, 28 May 2020 07:41:39 GMT - stdedos:

Also: Add a "Copy to clipboard" button (in any format you'd like - useful for #2783)

It could even be table format for WikiFormatting ;-)


Thu, 28 May 2020 10:26:52 GMT - Antoine Martin:

I meant to add the "Always On Top" boolean on the Windows Information window, not necessarily as a client-toggleable option :-D

It was already there, but very few applications actually request it so you're unlikely to see it. It is part of _NET_WM_STATE, which is shown as State on the window-info window. You can see it in action using the "States" tool from the xpra toolbox. (click on "Keep Above", aka stay-on-top)

There is no indication on the menu if it is set or not

I believe this is a theme issue, likely the same problem as reported in #2782. It's missing some assets, it was working previously, so maybe I trimmed too much in r26475. This CSS stuff is a nightmare to debug. It's also likely that when I re-add those assets, the headerbar will become bigger again... and maybe too big.

The size of the Always On Top entry is weird compared to the other ones, I am assuming because all the other entries contain an icon. Can you add a dummy-sized icon?

Now using a custom icon for showing the "ticked" state rather than a CheckMenuItem drawn by GTK and CSS: r26491.

Also: Add a "Copy to clipboard" button (in any format you'd like - useful for #2783)

Done in r26492.


Tue, 30 Jun 2020 09:12:15 GMT - Antoine Martin:

r26845 adds a command line option for controlling the headerbar:


Thu, 02 Jul 2020 05:33:49 GMT - Antoine Martin:

Best description I have found so far of the problem with GTK, size constraints and CSD: Maximize or fullscreen back-n-forth shrinks the terminal : gtk size negotiation nightmares: When creating a window you can't just call vte_terminal_set_size and let the system fit the window around that. You have to use gtk_window_set_default_size instead. But you need to know the difference in size between the window and the vte widget, and you can't measure that until after allocating a size to the window and realizing it and all its widgets. Things are further complicated because gtk_window_set_default_size seems to exclude the borders, but allocation and geometry hints include borders (and shadows).

Further down that ticket: This atomicity is something Wayland, Mutter, GTK etc. folks (I'm not sure who exactly) have to figure out.

GTK bug examples: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/129#note_654131


Maybe we could just not enforce size-constraints client side and leave it to the server instead? Use a temporarily fixed-sized drawing area (only until the window is mapped) to get GTK to honour the window size we actually want.


Thu, 02 Jul 2020 16:01:53 GMT - Antoine Martin:

As of r26860, we can use the headerbar in more cases: we use the drawingarea's size-request to ensure the min-size is still honoured when the headerbar is used.


Thu, 02 Jul 2020 20:05:10 GMT - stdedos:

Replying to Antoine Martin:

Best description I have found so far of the problem with GTK, size constraints and CSD: [...]

Sounds something like should be fat-stamped somewhere

Does the workaround proposed in the ticket (dconf write /org/gnome/terminal/legacy/headerbar '@mb false') work? Can it be applied only on XPRA-side? 😕

Replying to Antoine Martin:

As of r26860, we can use the headerbar in more cases: we use the drawingarea's size-request to ensure the min-size is still honoured when the headerbar is used.

Do I hear headerbar fixes ... or more issues?


Fri, 03 Jul 2020 06:40:10 GMT - Antoine Martin:

Does the workaround proposed in the ticket (dconf write /org/gnome/terminal/legacy/headerbar '@mb false') work?

Depends what you're trying to do.

Can it be applied only on XPRA-side? 😕

The xpra client has its own command line option now: --headerbar=on|off|force, on the server you can do what you want.

Do I hear headerbar fixes ... or more issues?

Fixes that allow CSD to be used and get GTK to create a window of the size that we request.


Sun, 12 Jul 2020 14:22:25 GMT - Antoine Martin: status changed; resolution deleted

Spotted a new problem: on mswindows, some windows don't render (all black) with opengl enabled, a header bar, and 24-bit mode. (windows with transparency do..)

Also #2747.


Mon, 20 Jul 2020 10:17:30 GMT - Antoine Martin: status changed; resolution set

It seems impossible to fix on win32, probably for the same reason we can't do transparency with opengl (#1682) as the headerbar also enables transparency for the whole window. So r26998 disables opengl on win32 if the headerbar is enabled, but it is no longer enabled by default on win32.

r26997 adds the missing man page entry.


Sat, 23 Jan 2021 05:54:00 GMT - migration script:

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