Plans for SimpleSteamTinker #7
Description
The main issues with SimpleSteamTinker are about distribution and stability.
Let me explain.
Distribution
Big number of files
SimpleSteamTinker, despite being an utility that I personally think should be as easy to set up as possible, is made of multiple files that currently all have to be installed together.
The inspiration for SimpleSteamTinker, SteamTinkerLaunch fixes this by... simply not having the problem in the first place (aka, it's all in a 27k line bash script).
Ideally, all those files should be compiled into a single one, for extremely easy distribution.
LGI
This is the more problematic issue : while LGI's latest development versions do "support" GTK4 & Libadwaita, its latest actual release is from 2017.
Most distributions do not have the development versions available, requiring manual installation through its Makefile.
Arch Linux and Arch-based distributions are an exception thanks to an AUR package, so at least there's that.
LGI relies on compiled C modules, so it is not possible to bundle it with the project either.
Stability
Lua was chosen for this project for two reasons :
- Speed, which was a very big problem with SteamTinkerLaunch.
- Simplicity, SimpleSteamTinker should be easy to update and modify for anyone. Lua is widely used in the video game industry in general as scripting language... making it the perfect choice for a tool dedicated to Steam modifications on Linux.
But, choosing Lua also means having to deal with its shortcomings, such as the lack of static typing, no const (excluding Lua 5.4) or switch.
In short, a lot of modern language features to help avoid mistakes are missing from Lua.
Additionally, SimpleSteamTinker barely makes use of pcall when performing operations that might fail, making the risk of a crash occuring quite big.
So, what can be done ?
Lune
Lune is a standalone runtime for Luau. If I can manage to make use of it for this project :
- We get access to Luau's typechecking system, on top of Luau's many other improvements. Woohoo !
- Lune's ability to compile Luau files (with darklua in our case due to the many files) would be precious.
- We can drop many of the currently required Lua libraries, exchanging them with modern, potentially faster alternatives :
| Lua | LuaFileSystem | LuaSocket + LuaSec | dkjson |
|---|---|---|---|
| Lune | @lune/fs |
@lune/net |
@lune/serde |
From all this, you'd think Lune would be clearly the future for our project... however, there is one major issue which I already discussed with CompeyDev on Discord (give her a follow btw, she's really cool :3) :
No FFI -> No way to interact with GTK / Libadwaita -> No interface (there goes the user-friendliness...)
Even when FFI is added to Lune, an LGI port or an alternative would be needed to interact with GTK and Libadwaita. Though, another UI library could also be considered.
Dang, so close...
Rust
I'm mostly suggesting this idea because I want to train myself to Rust. The benefits and cons are fairly straightforward :
Pros
- Stability goes through the roof.
- Blazingly fast. 🦀 🚀
- And 🦀 memory-safe 🦀 even though 🦀 this project is already 🦀 memory-safe 🦀 technically.
- Everything gets compiled into a single file.
- SimpleSteamTinker can follow a much more standardized approach in terms of development. Proper package management, documentation, linting, etc...
- We're forced to do (nearly) everything properly.
Cons
- Rewriting the entire project.
- Losing a lot of the simplicity of the current source code.
- We're forced to do (nearly) everything properly.