Changes for flatpak and other restricted environments (Linux)

[flagrama]

This PR adds support for running the randomizer in environments where the app directory itself is not writable. My personal motivation behind this was to let the randomizer run in a flatpak environment, however as I worked on this I realized it also helps resolve installing the randomizer in say /usr/local/bin or :\Program Files as well, although I've only made changes necessary for Linux environments currently. Windows should be handled by someone who actually uses the platform, possibly with an eye to also create a store package.

Changes:

• Python
  • Rename existing local_path and data_path functions to make it clear they should only be used for reading files, not writing.
  • Add functions for each of the directory types specified in the XDG Base Directory Specification
    • While all of these get used for Linux/Flatpak, other platforms may end up using the same directory for one or all of them
  • Implement the new functions in place of the old functions wherever custom user data is expected. Overall we had pretty good separation between always existing readable data and potentially non-existent user-provided data so this was easier than expected.
  • Create and copy any files and directories the user is supposed to be able to write to to the user directories. (i.e. create the music folder in the writable data directory, copy the conversion script to it, copy the music_exclusion_list to the writable data directory)
• GUI
  • Add a configuration to build without font optimization. Flatpak build environment has no internet access, and font optimization requires internet access.
  • Refresh package-lock.json. This hasn't been updated since 7.1, but the tool Flatpak provides for downloading node modules as sources prior to entering the build environment works off of this, and if the output from the package-lock.json does not exactly match what the package.json needs in the build environment, issues arise.
  • Ensure settings.sav is read and written at XDG_CONFIG_HOME if the app directory is not writable.
  • Have the default output directory checked when clicking the UI button to open it be XDG_DATA_HOME/Output if the app directory is not writable
  • Have the app directory button open XDG_DATA_HOME if the app directory is not writable
• Compress
  • I needed to add support for reading and writing the ARCHIVE.bin file from XDG_CACHE_HOME if the app directory is not writable.
    • Currently only x86_64 and AArch64 are built. Unsure whether to bother with ARM32 though.

Flatpak and Flathub

With these changes it is now possible to build a Flatpak for OoTR, so long as it is using this branch as its git source for now. I have created a repository with all the files needed to do so. If you wish to give it a try yourself, you should install Flatpak, the Flathub repository (tutorial for building has you install it user-wide, not sure if issues arise with a globally configured one, but you can have both installed at the same time) and the Flatpak building tools. I found all of these available from my package manager. If further help finding them is needed I can do so.

To build and install the Flatpak in that repository, run flatpak-builder --force-clean --user --install-deps-from=flathub --repo=repo --install builddir com.ootrandomizer.electrongui.yml then to run the Flatpak run flatpak run com.ootrandomizer.electrongui. It is also possible to create a file to share with other users if desired.

While that repository has the basics, we should decide if we want to distribute the Flatpak on ootrandomizer.com, or if we should submit the package to Flathub in which case there is still more required work to do. Other adjustments can be made as desired too.

[flagrama]

Also, here is a compare without renaming local_path and data_path for easier viewing: https://github.com/OoTRandomizer/OoT-Randomizer/compare/Dev...flagrama:OoT-Randomizer:flatpak-prep-norename?expand=1

[flagrama]

Could I request the label Component: Cosmetics as well? Most of the Python changes are specifically on custom cosmetics code.

[flagrama]

Okay, I think this is good for review now. I did have Dusk give the Flatpak a try, and seemed to patch models fine, and I've tested custom music. I'm going to upload a version of the Flatpak to the dev channel as well so I can link it here for more testing, though building for yourself should also work. Some testing should also be done with the branch and release build of it in a normal circumstance to make sure behaviour hasn't changed. I tried hard to make sure it wouldn't, but you never know.

I was able to cross-compile an AARCH64 version of the Compress executable, but my distro doesn't have packages for 32-bit ARM so someone else will have to get that if it seems necessary. Flathub itself will only create x86_64 and AARCH64 packages.

I can also change to the other branch without the renames adding readonly_ if desired, but I'd prefer having something more obvious like in this branch.

[Tri4ceKid]

Loving the work so far! I've noticed that custom voices aren't working; everything except "Silent" just uses the default voices.

[flagrama]

Thanks for the info. I look into it soon.

[flagrama]

@Tri4ceKid the new commit should fix the issue. Do you need a new flatpak made, or can you make one yourself to test?

[Tri4ceKid]

I would appreciate a new flatpak as I'm not yet familiar with the process of making one.

[flagrama]

Updated the link in the "ready to review" comment to a new flatpak build on discord.

[fenhl]

Minor code style nit, the Python looks good other than that afaict. Would appreciate if someone else could give the GUI code changes a review.

[fenhl]

I can probably take care of building the compressor for ARM32, just need to figure out how.

[flagrama]

I can probably take care of building the compressor for ARM32, just need to figure out how.

Feel free to add the commit with it directly to the PR

[flagrama]

8.3 flatpak uploaded to the Discord: https://discord.com/channels/274180765816848384/512048482677424138/1378940108392235179

[mracsys]

An alternate method to specifying the path to ARCHIVE.bin would be changing the working folder in the python call (see Main.py and Utils.py in PR #2314). This avoids the need to recompile the compressor for all platforms if that becomes a problem.

[flagrama]

This would still require changing the source code for the compressor due to needing dmaTable.dat as well. It's also not possible to copy to a user directory on install as a flatpak can be installed globally for the system further making dmaTable.dat a problem.