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). Ντέντος Σταύρος _______________________________________________ shifter-users mailing list shifter-users@lists.devloop.org.uk https://lists.devloop.org.uk/mailman/listinfo/shifter-users