Qubes-style forced window decoration

[lvh]

In Qubes, you run related software (e.g. personal, work...) in related Xen domUs for separation. In dom0, a window manager makes them visually distinct via a combination of window title prefix (which can not be set by the child VM/domU) and window decoration color. This still looks "seamless"

How do I accomplish something similar in x11docker? Can we get that with pure Wayland?

I can think of a few things that ostensibly work. --xpra and --xpra-wayland work really well. Window decoration appears to be mutter (I'm running Gnome 3)'s problem. Not sure if there's an obvious way to tweak window decoration color, which I've found very helpful for quickly determining what context a window lives in.

[lvh]

Secondly, of course, we can run Weston or whatever, but now we're purely relying on client side decorations, which is great as long as the client isn't trying to trick you with a UI redress attack.

[mviereck]

Container applications running with --xpra already show on 123456789012 in the window title. The number is the hostname of the container.
xpra also provides a customable window decoration: a colored rectangle around the inner window space. From man xpra:

--border=BORDER
              Specifies  the  color and size of the border to draw inside every xpra window.  This can
              be used to easily distinguish xpra windows running on remote hosts from  local  windows.
              The BORDER can be specified using standard color names (ie: red, or orange) or using the
              web hexadecimal syntax (ie: #F00 or #FF8C00). The special color name "auto" will  derive
              the  color  from the server target address (the connection string) so that connecting to
              the same target should always give the same color.  You may also specify the size of the
              border in pixels, ie: --border=yellow,10.

For other X servers like Xephyr and nxagent I don't have an idea right now.

Can we get that with pure Wayland?

There is some work done to port xpra to Python 3 and GTK 3. When that task is complete, xpra client (that shows the window) should run on Wayland without X and could provide a similar colored border.
xpra client could be able to show X applications in a pure Wayland environment.

Though, I doubt xpra server will be able to forward pure Wayland applications, except it will act as a Wayland compositor on itself. Most probably that is not on the current roadmap of xpra development.
But for a long time there won't be Wayland applications without X support, so this is not really an issue.

[mviereck]

I have added a new option --border[=COLOR] to draw a border into xpra windows. The optional COLOR argument can be specified like in xpra manpage. Default of x11docker is a a decent blue,1.

I have still no idea for windows created with e.g. --xephyr or --nxagent because window decoration options highly depend on the host window manager.

[lvh]

Whoa, that's some maintainer response! Thanks :)

Re: xpra; you're right! I was working with jess/cathode specifically and that seems to, somehow, set the hostname to the parent hostname -- but that seems fine.

When using --xpra-wayland I get a native-looking Wayland app (I get that XWayland is in the center). It looks native in my Wayland compositor (sway) -- and IIUC, that means the window decoration (e.g. title) is not controlled by the container?

[mviereck]

I was working with jess/cathode specifically and that seems to, somehow, set the hostname to the parent hostname -- but that seems fine.

You are right - xpra shows the host-hostname with jess/cathode, but the container-hostname with others. I am a bit confused why.

that means the window decoration (e.g. title) is not controlled by the container?

Yes. The container application sets a window title, but xpra controls it.

x11docker runs two instances of xpra, xpra server and xpra client. xpra is designed to run across a network where these two instances would run on different machines.

The container application runs on an invisible X server: Xvfb, Xdummy or Xwayland, a virtual frame buffer (vfb) in xpra terms.

On that vfb xpra server acts as a window manager. xpra server forwards the window content from the vfb to xpra client. The host X server has its own window manager where xpra client is a regular X client.

Because xpra client is the real client of the host X server, it controls the window title. It can be customized. From man xpra:

 --title=VALUE
              Sets  the  text shown as window title.  The string supplied can make use of remote meta‐
              data placeholders which will be populated at runtime with the  values  from  the  remote
              server.  The default value used is "@title@ on @client-machine@".

              The following placeholders are defined:

              @title@
                     Will be replaced by the remote window's title.

              @client-machine@
                     Will be replaced by the remote server's hostname.

x11docker now sets --title='@title@ [in container]'.
Additionally it would be possible to set the window icon (but it may be overridden by the application):

--window-icon=FILENAME
              Path to the default image which will be used for all windows.  This icon may be shown in
              the window's bar, its iconified state or task switchers.  This depends on the  operating
              system, the window manage and the application may override this too.

When using --xpra-wayland I get a native-looking Wayland app (I get that XWayland is in the center). It looks native in my Wayland compositor (sway)

sway runs Xwayland to support X applications. If you run x11docker with --xpra or --xpra-xwayland on sway, xpra client will run in both cases as an X client of sway.
The difference between --xpra and --xpra-xwayland is only a different vfb. This difference is present on xpra server side. Xwayland from --xpra-xwayland has nothing to do with Xwayland from sway.

In any case, xpra client does not run as a Wayland client of sway. That would need full GTK3 support of xpra.

[lvh]

(Sorry, I haven't had time to work on this, but I hope to pick up up Soon(TM). Everything you said made sense.)

[mviereck]

No problem ;-). Feel free to reopen if you have more questions or wishes.