I recently said on Twitter that I expected x2go to have what I considered significant limitations for my ongoing use of remote X. This isn't because of any specific flaw in x2go; instead, it's because of a fundamental difference between remote X and what remote desktop software like x2go does even when it's implementing what the Wikipedia comparison of remote desktop software calls 'seamless windows'.

Normally, remote desktop software like x2go gives you an entire remote desktop in a large window. When the remote desktop is on a Unix machine, this is normally done by starting an X server (or perhaps a Wayland server) that's drawing on a chunk of RAM as a virtual framebuffer, instead of to a GPU and one or more physical displays. The X server then tracks changes to this virtual framebuffer and sends them to your local client, which displays them. Local X input events flow in reverse; your local X server sends them to the local client, which wraps them up in some protocol and sends them to the remote X server, which then passes them on its clients. Because what's running is a remote X server, it can run a full (X) desktop session (assuming that the remote X server supports all of the X extensions that the particular sort of desktop requires).

To implement a 'seamless window' in this model and get something like what you see when you run 'ssh -X xsomething', the straightforward approach is for the remote desktop software to still start a remote X server but only run a single X program that talks to the server, the remote program you want to start. The local RD client and the remote X server work together to only show you the area of the remote X server's virtual framebuffer that the single client's window occupies.

However, just passing the drawn pixels and the X input events back and forth is only part of having a real remote X program. A true remote X program can see and update X properties, it can participate in at least X's cut and paste systems, letting you copy things in and out of it, it will have proper window titles and desktop or taskbar icons (and it will be able to update its window title, as some programs do), it can appear and disappear (being 'mapped' or 'unmapped'), and it can ask to be placed at a specific location (and there's more). Full support for X properties requires not just access to X properties on the root window, but access to X properties on other client windows; this is how Firefox's X remote control works (cf).

If you're running a full remote desktop session, you don't want a lot of this. Perhaps you want some sort of cut and paste back and forth for convenience, but it's generally a feature that the remote desktop's root window X properties do not become your local root window X properties (and vice versa), for example. This means that a basic implementation of seamless windows with a remote X server won't support any of this. Adding some of this stuff is possible with code that's specific to the seamless window feature, but supporting everything becomes extremely difficult. In particular, a remote program seeing and updating X properties on your local windows pretty much requires an entire set of phantom windows in the remote X server.

(I was going to say that you'd also have problems if the remote program (or things started from it) wanted to open more top level windows, for example because you started GNU Emacs inside your remote xterm, but apparently at least some 'seamless window' implementations manage to handle this (or claim to).)

Pretty much all of the X programs that I run remotely require some or all of these advanced remote X features (including multiple independent top level windows). A 'remote X' system that performs better than 'ssh -X' but doesn't support most of these features isn't terribly useful to me.

(I talked about this a bit in my entry about my failure with Xpra, but I didn't get into detail about why this is hard and at odds with the 'remote desktop' approach.)