[winswitch] xpra: probe for active sessions
stdedos at gmail.com
Mon Sep 23 09:15:38 BST 2019
In some of my bug reports, it appears that I am doing a mistake of
"specifying" where to start xpra instances.
[i] One example is trying to start on a screen that already exists.
However, it seems complicated to my usecase "not" to specify a screen
1] I usually have 2 sessions active (`xpra shadow` and `xpra start
2] I'd like not to keep stale sessions active
For [i], I would assume a fail-fast (instead of a timeout) client-side
solution would quickly inform me that "try to attach instead". It could
even automatically/interactively ask to do so?
For , I'd assume that `--start-child` / `--exit-with-child` would help
(I don't use it, since I think I had issues with it. I'll try to dig on
However, what's the behavior on children started from that process?
Children started from `--start-new-commands=yes`? Is it wait-all, or simply
polling the pid of the initially started process?
What if multiple `--start-child` are given?
I assume that `xpra attach` (plain) would try to attach to the exactly-one
child active on the server.
To "solve" , is it acceptable to, otherwise, provide an error message
Cannot decide where to attach. Please specify applicable screen:
Additionally, for `xpra list`:
Can the screens have names?
And/or specify "how" they are started? xpra client can tell `xpra
gnome-terminal :20` or `xpra compiz :0` (or equivalent) on the tray icon.
Can `xpra list` do that too?
I can create the tickets myself, if you believe that the missing features
are well-defined (or you can reply with links yourself).
More information about the shifter-users