I see on the home page:
> ROXTerm uses the "session" bus, which should be started along
> with your desktop environment.

Does this imply that ROXTerm cooperates with GNOME session management, and including ROXTerm in a saved session will result in ROXTerm restoring itself to the same state when the session is restarted?

If so, what kind of attributes are preserved by the session? Are the tabs and titles preserved?

-Tom

This is something I've wanted, and all it needs for a shell is an extra environment variable which gives the terminal number (not the session Id type thing which changes every time, but the window number). I have code which I have added to roxterm.c (in version 1.12, I think) which does that, it creates ROXTERM_NUM which has the terminal number (it repeats if you use --separate, but something could be added to detect that in the shell). I then have code in the shell startup script which detects that it's a login shell, looks for that environment variable, and sources the appropriate cd and history (it's in zsh, but something similar can be done in bash). The shell writes the directory and history before every command (or can do it when the shell is closed for bash).

I'll be adding this to the feature request list, and can supply a patch diff for it.

No, ROXTerm doesn't support session saving, but it is possible to open new tabs from the command line so you can arrange to start ROXTerm in a certain state to a limited extent. See <https://sourceforge.net/tracker/?func=detail&aid=2056919&group_id=124080&atid=698431>.

The "session bus" is part of DBus, which isn't really part of session management; I use it to send configuration messages between ROXTerm and its config applet which is a separate program.

> No, ROXTerm doesn't support session saving...

That's too bad. Definitely a killer feature. I'll add it to the feature wishlist.

Some thoughts on session management in terminal emulators in this thread:
http://www.nabble.com/persistent-xterm-sessions-td17704752s24859.html

> The "session bus" is part of DBus, which isn't really part of
> session management;

Really? I had gotten the impression somewhere that DBus was utilized as part of GNOME session management - how it communicated to the application the session ID and requested that the session be saved or restored.

> ...it is possible to open new tabs from the command line so you
> can arrange to start ROXTerm in a certain state to a limited extent.

I would be satisfied with a semi-automated solution in the short term, which should be doable with a few minor tweaks. One apparently missing ability is the ability to set a tab title.

I briefly poked through the code hoping it might be possible to do this via DBus, but I'm gathering the only "verbs" supported by DBus are the ones to set config settings and stuff already defined as command line options. While a command line option would be more convenient for this particular need, you might want to make all of the actions accessible via menus also callable via DBus.

Anyway, back to session persistence...if I could run a script to create a desired set of named tabs, each executing a command, that'd be a start. If I could then get the CWD, history, and scrollback of each tab to be persistent across crashes and sessions, that'd be terrific. (For local shells, where screen doesn't help you if the machine crashes.)

Some of this could possibly be hacked together using some scripting that keyed off of an ID unique to each tab (like the ROXTERM_ID, but unique to the tab and consistent across session; probably set via a command line option) so you can restore the correct shell command history, CWD, and 'cat' a log of the last N lines of terminal output.

A first cut at internal session management might be saving the current list of tabs, their titles, CWD (which ROXterm already seems to be aware of), and affiliated settings profile. They could be saved every N minutes, and automatically restored on restart. A future addition could be making the scrollback history part of the session data.

-Tom

> > The "session bus" is part of DBus, which isn't really part of
> > session management;
>
> Really? I had gotten the impression somewhere that DBus was
> utilized as part of GNOME session management - how it
> communicated to the application the session ID and requested
> that the session be saved or restored.

Possibly DBUS is used as the implementation, but AFAIAA the API is
provided by libsm so if it does use DBUS that's all hidden away.
DBUS is a general purpose IPC.

> Anyway, back to session persistence...if I could run a script to
> create a desired set of named tabs, each executing a command,
> that'd be a start. If I could then get the CWD, history, and
> scrollback of each tab to be persistent across crashes and
> sessions, that'd be terrific. (For local shells, where screen
> doesn't help you if the machine crashes.)

Using a script like that is definitely possible, you can also set
the cwd of each tab by using cd before each roxterm command.

Preserving the command history per tab isn't really possible;
that's a function of the shell and as far as the terminal is
concerned, the shell is just an application running in it and it
doesn't have any awareness of its state. If you run more than one
interactive shell at a time or you don't exit the shell cleanly,
the command history won't be preserved. And without the terminal
being able to be aware of the state of the program running in it
(whether that's the shell or something else) I don't see much
point in preserving the scrollback buffer TBH.

To get what you want I think you need to be asking shell
developers to add major new features, as well as, if not more than
terminal developers.