On Wed, Mar 4, 2015 at 9:37 AM, Mihai Moldovan <ionic@ionic.de> wrote:
You cannot attach to running sessions, but you can forcefully suspend a running session from the client and then attach to it. Is there some reason for that? I preferred the NX/freenx approach where the new connection would automatically grab the existing session (since you obviously wouldn't be trying to reconnect if you already had a running client on the computer you are currently using).
I don't know. I can only guess, that running sessions are to be left alone (in case it's being worked on from some other machine)
In my case, it is always because I left it running on my work desktop, forgetting to suspend when I left but now I want to pick the session up from a different location (laptop or home Mac) and continue.
and that in most cases a new session makes more sense than sharing a session. I also do not know how well session sharing works in general. (That's just not my use case, sorry.)
I don't want to share a session, I want to move it to the client where I am now, resizing if necessary to fit. NX/freenx handle this wonderfully, but I don't like their current Mac client and freenx isn't available for RHEL/Centos 7, so I'm hoping to be able to switch to x2go for the same functionality.
I don't like this, because it's inconvenient if you explicitly want to start a new session with the same characteristics. In my opinion, the session list should always be provided if one session (no matter the settings or state) is running on the server. I disagree - I _always_ want to reconnect to my existing session, across different clients and I'd rather not have to do unnecessary work suspending/retrying or picking one session from a list of one just because my laptop and mac screen sizes don't match my windows desktop where the session was likely started. If you are going to change this behavior, can you please make it configurable so people who only start one desktop session per host can always reconnect without extra confusion, including automatically grabbing the session you forgot to suspend before leaving your desk?
There's one point you're missing: it is currently *impossible* to start a new session without knowing the exact workaround, if another session with the same characteristics is running.
Maybe add a checkbox option to force a new session? If that's what you want, then it won't matter whether or not one is already running.
Maybe that's an edge case not concerning most users. When it comes to myself, I do need it quite often. For instance, I use to start multiple rootless xterm sessions for testing purposes when trying to reproduce bugs or test new features/whatnot and *don't* want to disturb other xterm sessions that are supposed to fulfill a particular purpose (e.g., "video editing".)
I guess I don't understand why you would do that as opposed to letting them run in a window manager session where they could open/close without affecting each other yet still be easily picked up (together) by a different client connection. That is, work as though you were at an X desktop at the console of a machine and grab the whole desktop to your client. If you are working on multiple nearby hosts, you can use ssh X forwarding to get all of the windows on one desktop just like you would if you were working there directly.
If there is one xterm session started, it is currently impossible to start another one, without first starting some session that is not of xterm type.
Is that some internal quirk of x2go? I guess I can understand why you might want to start multiple new sessions doing rdp or with a similar proxy approach to a different target. But if you want multiple windows on the same host, why not just let a window manager session manage them with a single connection?
Aside from always wanting access to my same set of open windows and long-running programs, I've had problems with some desktop environments and GUI applications with concurrent sessions for the same user. Some of them maintain hidden files that don't handle concurrent updates gracefully, and some (like firefox) may try to open a new instance as a new window in an already running session (which may not be the one you are displaying). So - starting a new session if you already have one just seems wrong, especially if the session is of the same desktop environment type.
That's true for desktop sessions and specific applications which are supposed to be started only once, yes.
There are valid reasons for multiple sessions, though, as outlined above. I can't say how widespread those use cases are, though. It may be only me, in the worst case, and I acknowledge that.
I can see having an option to force a new session even if one exists - and maybe it makes sense in the context of single-application windows if you want to manage them the hard way. But, I'd just like to minimize the extra steps you have to do to start up a client - and my scenario will almost always be connecting to an already-running Gnome or MATE desktop where I may or may not have forgotten to disconnect another client and the client where I am now may have different screen geometry.
-- Les Mikesell lesmikesell@gmail.com