Multi-toon controller for Toontown-based MMORPGs. Uses X11 and GTK, and is designed for use with GNU/Linux operating systems (but possibly works on anything that is using X11 as a windowing system).
toonmux is in an ALPHA state, and should only be used at your own risk!
This will continue to be the case until the version of toonmux is >=0.1.0.
toonmux adheres to version 2.0.0 of the Semantic Versioning specification.
- X11
- GTK
>=3.22 && <4.0(including development files,libgtk-3-devin Debian) - libxdo
>=3.0 && <4.0(including development files,libxdo-devin Debian) - rustc & cargo
git clone https://github.com/JonathanHelianthicusDoe/toonmux.git
cd toonmux
cargo rustc --release -- -C target-cpu=native
strip ./target/release/toonmux
./target/release/toonmux- Multiple controllers (up to 64* simultaneously) with independent bindings
- Rebindable main controls (the controls that all controllers’ bindings map to)
- Collapsable UI (minimal screen space while still being focusable with the mouse)
- Ability to have a controller mirror another controller
- toonmux’s state is automatically persisted to disk as JSON
- Ability to re-bind controller from one window to another
- Special binding for a “low throw” of cream pies/evidence
- Ability to add controllers
- Ability to remove controllers
- Speedchat+ support
- Ability to toggle mirroring globally on and off using a key press
- Bindable controls for viewing gags and tasks
- Automatic keep-alive
*Actually 32 on 32-bit architectures.
If a controller A is mirroring a controller B, then A’s own
“talk” hotkey gets suppressed; in this situation, the only way for
you to use Speedchat+ with controller A is by using B’s hotkey. If
this is not desired, you can just toggle off mirroring before chatting.
The GUI ecosystem for Rust is not very mature yet, and essentially all of the options for making a GUI in Rust are either too immature for serious use (and may possibly vanish at any time), and/or perform unacceptably poorly for use in something that should just be a lightweight desktop applet.
As a result, toonmux uses gtk-rs, which are just Rust
bindings to GTK. Unfortunately, GTK is a
C API that is not
only geared towards more “object-oriented”/“classical”
(read: spaghetti) approaches to
GUI, but also does not in any way respect the ownership model of Rust. This
means using a lot of atomically reference-counted pointers
(Arc) that get passed
into closures, as well as internal mutability (mostly in the form of atomics
for toonmux, but also reader-writer locks & mutexes). This is essentially
writing out explicitly things that are required to be used anyways to use GTK
safely, but Rust doesn’t have the luxury of a large runtime to make
things easier (c.f. PyGTK).
That being said, toonmux is still written in Rust in order to stay as responsive and lightweight as possible while still being safe (for some value of “safe”).
The only things wrapped in Arc are the global “state” and the
global UI state. Holding weak references is obviously useless in this case
because the global state never gets deallocated. Only holding references to the
“root” of global state might seem like an unfortunate choice, but
it works quite well since there is no actual graph structure, ownership-wise
(except internally in GTK’s implementation of the UI).
Because I’m a coward. Also because I expect the synchronization
bottleneck to be at the level of the RwLocks anyways, not the atomics. If
you’re an atomics-semantical wizard, feel free to submit a PR to weaken
the ordering constraints…
toonmux is licensed to anyone under the terms of the GNU General Public License, version 3 (or any later version of the same license, at the licensee’s option).
