Changelogs » Tmule



This release has some new features:

1. _`wait` per window:_ Rather than one global wait in seconds for auto-launch, you can now configure a wait time for each window (i.e., auto-launching will only commence after waiting specified seconds)
2. _`check` process:_ You can specify a process that is run to check if a window is up. This can be any shell expression. If the exit code is `0`, then the window is deemed running. For instance `rostopic list` is a good check process to ensure that `roscore` has completed its starting up.
3. iterating through all windows for termination is done in reverse order now


There is now a new TMule Release (version [`1.2.0`](, which implements the following:

* **named session support:** a new key in the main config file allows to define the name of the tmux session. Useful if several tmux sessions are needed, use top-level key `session`.
* **tag support:** each window is assigned a list of tags.  `launch` and `stop` commands support a new flag `-t` (can be used multiple times), to indicate all the tags that should be launched. Idea is that we can launch specific systems from _one_ tmule file, e.g, everything needed for navigation demo gets tag `navi_demo` and you launch only that tag. Another one may be using tag `data collection` indicating it launches everything for data collection. Tags are now also supported by the server mode, i.e., in the web interface all windows of a specific tag can be launched or stopped selectively.
* **skip support:** an optional key `skip` can be set true if the window should be exempt from launching when "all" is selected (useful for manual debugging windows, that should only be launched specifically)
* **parameter support**:     tmule supports a few parameter substitutions in the config file. All parameters are surrounded by ``:
- The absolute path of the config file: `TMULE_CONFIG_FILE`
- The absolute path to the directory of the config file `TMULE_CONFIG_DIR`
- The name of the tmux session: `TMULE_SESSION_NAME`
This is particularly useful to refer to any other files required (e.g. workspaces, config files, etc) that are defined relative to the location of the tmule config file, hopefully simplifying some setups.
* **reload support:** In _server mode_, reloading the website will also reload the config file, i.e., the server does not have to be restarted when the config file is edited. This eases debugging and adding features on the fly a lot. It also allows to launch server automatically (e.g. via `supervisor` as we do in Lindsey etc) in all robots and then keep it running forever.  If we have _one_ tmule file for all sub-tasks, then these tasks can easily be launched and stopped via the web interface.

Just run `pip install -U tmule` to get the latest version.

See example file [`tmule.conf`]( for all the new features. And new server GUI below: