My dream: I want a way to arbitrarily close and later open groups of applications including their states such as open files, window arrangement, scrollback, even undo histories etc. So working on a specific project I can close everything neatly and return to it later.
In my research/experiments here is what I come up with, do you agree?:
-
in the terminal-only environment this would be tmux or another multiplexer
-
But when you start including GUI applications (which I must), then it is something else that doesn’t exactly exist
-
Applications store their current states in a variety of places and some of them don’t really do restoring in any way so it would be hard to force.
-
the best option for this is something like xpra where you can have multiple sessions. If you had a machine that stayed powered-on all the time it might be possible to create sessions, log in remotely and use them that way.
-
Using xpra or similar the sessions are never really actually closed. You would only close the connection from the local machine. If the machine faces a power off then too bad. As far as I can se there is basically no way to accomplish this goal where power-offs are accommodated.
I have tried some remote-login options but they are too slow for normal use. I tend to have pretty low-end hardware running (because so far it works for most things) so maybe if I upgraded it would improve.
- is it plausible?
- how to estimate hardware/performance needs of host, client and LAN? anything else to consider?
I typically use manjaro + XFCE but would be willing to try something different to accomplish the goal. I only want to do this locally on LAN not remotely.
re XFCE session manager
XFCE has session management but the majority of programs don’t totally work with. Like maybe the application will re-open when the session is restored but no files will be open even if they were when session was saved. Or distribution through workspaces, window size etc will not be restored.
Look into QubesOS
https://forum.qubes-os.org/t/getting-the-restart-state-of-running-vms-via-a-script/20661