[BUG] When running in flatpak, steam shortcut has the wrong path
Describe the bug
When running Rare inside a flatpak, the Steam shortcuts created point to the wrong directory.
To Reproduce
Steps to reproduce the behavior:
- Install rare as a flatpak
- Add a game
- Right-click and add steam shortcut
- View steam shortcut referencing /app/bin
Expected behavior
The steam shortcut should use flatpak run io.github.dummerle.rare
Screenshots
If applicable, add screenshots to help explain your problem.
System information
Please complete the following information
- Operating system: [e.g. Manjaro/Windows 10] SteamOS
- Version: [e.g. 1.6.2] 1.11.3
- Installation method: [e.g. pip/msi/AppImage] flatpak
- Python version: (if installed through
pipor your package manager)
Additional context
Add any other context about the problem here.
Error message
You can find logs in these locations
| OS | Path |
|---|---|
| Windows | C:\Users\<username>\AppData\Local\Rare\Rare\cache\logs |
| Linux | /home/<username>/.cache/Rare/Rare/logs |
| masOS | /Users/<username>/Library/Caches/Rare/Rare/logs |
The flatpak version of Rare is not something I personally use, and at this point it is probably well outdated and behind the other pre-releases. If anyone wants to offer their time and effort to maintain the flatpak-related aspects of Rare, they are more than welcome.
Flatpak uses version 1.11.3 which is the official full release on GitHub, but was over 9 months ago. If I integrate beta flatpak releases into the github action would you be open to merging?
Yes, and we have a repo for our flatpak here with the flatpak GH action already set up. I am just not using it so as a result I rarely look into updating it. The boilerplate is already there, there is just no maintainer right now.
Edit; I guess you already found that repo. The flathub repo is not maintained by myself but by the other maintainer who is not particularly active right now. They still merge stuff when a new release is made.
Would it be worth including it in this repository instead of standalone? Alongside the other artifact building workflows?
In my opinion no, because that other repo is also used to push to flathub. I am not completely against it, if it makes sense later on, but I prefer it to be it's own repo for now.