Idea: Linux Support / Multi-Platform compatibility (I'd love to help contribute!)

[josiasdev]

Hi TroubleChute and team! First of all, amazing work on this project. It's a lifesaver.

I'm currently gaming on Linux Mint. To switch accounts here, I've been using a Python CLI tool called steam-acolyte, which works under the same principle as TcNo: swapping Steam config files without touching passwords or 2FA.

While steam-acolyte is great for Steam, the Linux gaming community is growing fast, and we lack a unified, beautiful GUI tool like TcNo Account Switcher that can handle Steam alongside Epic, Battle.net, and EA App (which we currently run through Wine/Lutris/Bottles).

I would love to contribute to bringing this project to Linux. I know this involves some major architectural challenges, such as:

1. UI Framework: Migrating the frontend to a cross-platform solution (like Avalonia UI or .NET MAUI).
2. OS Abstraction: Creating an interface to handle Windows Registry vs. Linux config files (~/.config, ~/.local/share, etc.).
3. Wine Prefixes: Adding logic to locate simulated Windows environments (Prefixes) for launchers that aren't native to Linux.

Before I start digging into the code or writing any PRs, I wanted to ask: Are you open to this idea? If so, how decoupled is the current UI from the backend logic, and where would be the best place for me to start experimenting?

Thanks for your time and for making this open-source!

[TCNOco]

MAUI ended up with many many issues... Some of which Microsoft are at fault for and just flat out refuse to fix. It's not the way forward.

I have done major refactoring and rewriting into Go. Much higher performance, incredibly small package. Still a WIP, but most features are ported across already.

While some of the code will drastically change, a lot is already production-ready.

See https://github.com/TCNOco/TcNo-Acc-Switcher/tree/go

Linux and MacOS support are planned. I haven't got far into it, as I'm trying to get features 1-to-1 and better than the original Windows-only version for now. I'm 90% of the way there I'd say. Just need to plan for and test updates as the last major feature. Wailsv3, the new frontend does provide such functionality as well as out-of-the-box support for Linux and MacOS using their built in browsers.

Thanks for the steam-acolyte mention, I assume that every major distro and their unique package solutions like Snap, AUR and more have the important files in different locations. While the program has support (and improved support for multiple default directories in the Go version) I haven't looked much further than "It's something I want to do".

[josiasdev]

Hi again! Thanks for the detailed update.

Moving to Go and Wails v3 sounds like a fantastic architectural choice. It avoids the headaches of MAUI, keeps the footprint incredibly small, and provides a great native-feeling cross-platform experience. That's awesome!

I really want to help out in whatever way is most useful for the project right now. Since you are currently focusing on reaching 1-to-1 feature parity for Windows and finishing the update system, how can I best contribute without stepping on your toes?

A few ideas on how I could help right now (or in the near future):

Linux Path Mapping: As you mentioned, Linux has various package managers (Flatpak, Snap, Native, Lutris/Wine prefixes) which scatter config files everywhere. I can start researching, documenting, and testing these default directories for Steam, Epic, and Battle.net on Linux so they are ready to be integrated into the new Go directory support system.

Testing the go branch on Linux: I can pull the go branch, set up the Wails v3 environment on my machine, and start testing what already compiles on Linux to track down early OS-specific bugs.

Frontend/UI: If there are any UI components or Wails integrations you'd like to offload, let me know.

Let me know what path makes the most sense for you right now. I'll start taking a look at the go branch in the meantime. Thanks again for all the hard work!

[TCNOco]

Almost everything is done, I'm just waiting on the free OSS signing certificate to release in Beta for Windows. In the coming few hours to day or so I will add a Platforms.linux.json and Platforms.mac.json - For specific file/folder actions on those systems.

As for package managers and installers - I assume everything except Windows emulation through Wine (and related) should be +- the same with loginusers.vdf for Steam existing in a home directory? I honestly have no idea about the location of home/user files in terms of the different installation means. This is the main issue I'd have to look into.

The Platforms system allows programs to be installed in multiple locations, but user files, cached logins etc are all located in the same place on all systems (Typically AppData or Documents), and if it's the same on Linux and Mac it'd be easy.

If Flatpack puts userdata in one folder, Snap in another, Native installs in another, and so on it could be rather difficult... I'm not sure if we'd just throw all the locations in for a platform and have it attempt to move all files, or something along those lines? It would work and I assume most users won't exactly have 3 different unique installs of Steam, etc.