search

TheTrackerCouncil / SMZ3Randomizer

Tracker presents: a casual standalone version of the Super Metroid & A Link to the Past Crossover Randomizer with built-in automatic item tracking and Twitch integration
https://vivelin.net/projects/smz3
MIT License
26 stars 8 forks source link

(Proposal) Linux Support #383

Closed MattEqualsCoder closed 5 months ago

MattEqualsCoder commented 1 year ago

So, I'm currently in the process of trying out Linux, and as expected, SMZ3 doesn't work! Here are some of the issues I was able to sort of identify:

  1. Some directories used are specific to Windows, such as localappdata. Linux would need to use different directories for logs and stuff like that.
  2. WPF is only in the .net windows SDK rather than the generic .net SDK. So, the UI just won't build at all on Linux. Technically I think it could run in Wine if there were a version that didn't go through an installer.
  3. The speech recognition and text to speech rely on core Windows APIs that I'm not sure would even be available to Wine. I think we'd need alternative interface implementations that basically wouldn't do anything on Linux.

Of the above issues, I think the second one is probably the least trivial to overcome. I'm not sure of any good way to get around it outside of redoing the UI to not rely on WPF. The MSU Scripter was written in AvaloniaUI, and overall I thought it was quite nice and shares a lot of the same XAML as WPF. But I know there are a couple other cross platform libraries.

For overall approach, I can think of a few options.

  1. Completely rewrite the UI for all platforms
  2. I could create a fork for a Linux version so that this repo can stay as-is
  3. A new project could be added with a potentially smaller UI. For example, the settings could be driven by a commandline interface, then it jumps right into the tracking window.

Just tossing this out there for discussion and thoughts.

MattEqualsCoder commented 1 year ago

Adding to this, I think there are a few things we can pull out of the Randomizer.App project as they don't really need to be there. It made sense before we pulled out the shared stuff into Randomizer.Data and Randomizer.Shared, but at this point we should probably try to keep Randomizer.App to just UI specific stuff.

Primarily, the RomGenerator and MsuGeneratorService classes can probably be rolled into Randomizer.SMZ3. Perhaps we could even move the Sprites into a separate Randomizer.Sprites project?

Vivelin commented 1 year ago

The first step is definitely to pull out stuff from the front-end project into the other libraries.

After that, I'm not sure. I personally don't care about Linux, certainly not enough to overhaul things, but I haven't had the time and energy to work on anything myself anyway, so it doesn't matter too much to me. Ideally, the front end should only be a relatively small part of the code base anyway.

I'm not sure what the requirements for a Linux version would be, anyway. Would a pure command-line version be enough?

If not, I'm still interested in .NET MAUI, which is also based on XAML, so it should be similar enough. The last time I worked with it it worked well enough, although it lacked some things so the UI framework we use might just take some trial and error.

Not in favor of forking it just for the UI. I'd rather have it all in one place, whether it's a single multi-platform UI or multiple platform-specific UIs.

MattEqualsCoder commented 1 year ago

Yeah, I'll be the first to admit I'm probably the only one interested in this. Lol Maybe CPColin since I know he runs on Linux, though he's had problems getting C# apps running on Linux from my understanding (not sure if those were Linux native C# apps or Windows ones running in wine). Possibly Pink as well since she's talked about switching to Linux, but any version of Linux would most likely not have any sort of voice support, so she'd possibly still want to use the windows version for that.

Long story short, I may be the only person who would actually use it. Lol but I'm willing to be the one to do the heavy lifting, and I certainly don't want to make things a hassle for others to develop.

I can look into MAUI and do some testing with it, but I've heard some pretty negative things overall. Lots of half baked features and Microsoft kind of already seemingly losing a bit of interest in it. I know it's technically cross platform, but I believe Microsoft leaves the Linux port to the open source community, so I dunno how fleshed out it is. Still, I'll do some digging into it and see. I might make a test app and see what I can do.

Overall, i will say my main goals would be...

  1. Make sure the Windows version stays the priority and doesn't lose any current functionality
  2. Have at least a Linux UI with a map and item tracker. The got thing is that these are mostly driven from configurations, so for the most part changes to one OS would apply to the other.
  3. Limit the burden on you, CPColin, or anyone else working on this.

Ideally, it would be great if the two were fully in sync outside of voice. But if MAUI doesn't do what we need and if a full conversion to a third party UI like Avalonia is out of the question, then it may just mean a separate, super bare bones Linux project.

So yeah, I guess the next step is for me to give MAUI a shot to see if it'll meet our needs.

MattEqualsCoder commented 1 year ago

So yeah. Looking into MAUI more, and it just doesn't seem like it would be the right avenue to go down for this purpose. Microsoft hasn't committed to making MAUI run on Linux, and the community driven one seems pretty far behind and lacking in support. Admittedly I'm not entirely sure why the MAUI Hybrid version doesn't run on Linux, but I'm not sure we'd want to go down that route anyway.

If the goal were a cross platform UI, I think we'd have a few options:

  1. Avalonia UI - Again, this is what I used in the MSU Scripter, and it seems pretty good. There are some wonky things, but I sorted out those for the MSU Scripter. Either doing a Linux-only UI or doing a cross platform UI, this would probably be my choice.
  2. Electron.Net - Everyone universally loves Electron, right? Right?! Seems decently supported, and Electron is... fine. Would not be my first choice, but I wouldn't hate it either.
  3. Photino - Based on my research, seems sorta like Electron but faster yet less supported.
  4. Gtk# - This is technically an option!

Again, my leanings are toward Avalonia since it's more familiar, seems to work well, and has no evidence that it might be going away any time soon.

But, my first priority will just be trying to get it to where I can easily develop and test without running in a VM. So my first goal will be just making a separate project in the solution (Randomizer.CrossplatformApp?) that will start as a command line tool for generating seeds and auto tracking. After that I can start working on stuff like the bingo goals and maybe slowly build up a UI over time. And who knows? Maybe by the time I get working on the UI portion, MAUI will be better ported to Linux and be more complete in general.

MattEqualsCoder commented 11 months ago

So thinking on this, something I may consider assuming a single shared UI isn't going to happen, is to move some of the UI into configs which can be shared. That way when a new setting or randomizer option gets added, it can be added to both easily. Could make some aspects a bit easier when upgrading in the future to MAUI or anything else.

Vivelin commented 9 months ago

I briefly looked into this, and one person on Reddit ended up using a MAUI/Blazor hybrid for Windows (and Android and iOS, but that's hardly relevant for this) and Photino/Blazor for Linux. I agree a true single shared UI is unfeasible, maybe we could try the same approach?