[winswitch] xpra: probe for active sessions

Σταύρος Ντέντος stdedos at gmail.com
Mon Sep 23 09:15:38 BST 2019


Hello there,

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
number, since:
1] I usually have 2 sessions active (`xpra shadow` and `xpra start
gnome-terminal`)
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 [2], 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
that one).
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" [1], is it acceptable to, otherwise, provide an error message
roughly saying:
Cannot decide where to attach. Please specify applicable screen:
`xpra list`-output

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 mailing list