Update the permissions

[orowith2os]

This is just some simple stuff.

XIVLauncher now uses --persist rather than --filesystem=~/.xlcore, as flatpaks should try not to mount in host paths like that.

When Wine tries to make symlinks, they will be removed after the app quits. To fix this, Wine should be configured to keep the home folder isolated. See https://askubuntu.com/questions/278992/how-to-keep-wine-from-creating-directories-in-my-home-directory

[flathubbot]

Started test build 34750

[orowith2os]

@bitsofabyte I mentioned a fix for the wine symlinks here. You can also add sdl2-with-libdecor from https://github.com/flathub/shared-modules if you want to let the launcher work on native Wayland.

[flathubbot]

Build 34750 failed

[Blooym]

How does --persist handle existing installations found at ~/.xlcore?

[orowith2os]

The already existing installations will require manual intervention to move to their new places in /.var/app/APPID/.

It's probably not feasible to automatically move them without some work from Flatpak's side of things. There was something for dconf entries though.

[Blooym]

The already existing installations will require manual intervention to move to their new places in /.var/app/APPID/.

I don't think it's really feasible to change where it stores things now if it requires manual intervention as many users on both deck and desktop won't really understand how to do it, I think it might be better to just lock it down to ~/.xlcore without the persist and leave it at that

[orowith2os]

Imo flatpak standards are more important here, it's not too hard to move the xivlauncher files anyways. Users should be used to some terminal-related work with XIVLauncher, it could go in a FAQ section on the website.

[Blooym]

I mean in an ideal world sure, but as I've observed from the linux support channel users already struggle getting the launcher installed when its from an app center, if we were going to go forward with following flatpak's standards we should be doing it for them.

I honestly think we should just lock it down now and then in the future implement some logic to get ready to use a persist instead. Goat has the final say on the idea, though.

[orowith2os]

If you don't want to break current setups, XL could instead start to follow the XDG base directory specification. The filesystem permission for ~/.xlcore could be kept, but future builds would move it to the proper directories.

[Blooym]

As much as I'd love for XLCore to follow XDG specifications, I have a feeling that isn't going to happen for a long time just based on how things have moved with the launcher over the last year. I feel like just leaving it at ~/.xlcore for now is better, and at least with new permissions we're not giving access to the entire home directory.

[orowith2os]

Its not too hard to follow the specs, they're just environment variables and define where to put files if they (the variables) don't exist.

Moving legacy files to the new directory can be done very easily with a simple script too.

[NotNite]

XLCore doesn't have a proper set of maintainers ATM, so proposing a change that would require coordination from users, developers, and support team, sounds infeasible right now.

XDG standards are wonderful to follow, but it is really not the end of the world if it's stuck in a dotfolder in the user's home for a while. The idea of "flatpak standards" being important enough to push through this effort is kind of silly (especially when people are looking into XL as a SteamOS addon, which comprises most of the userbase).

[orowith2os]

I'll look into making XL follow the standards on my own time, but until then, I'll wait for the wine build by y'all to be configured as standalone (no home symlinks), at the very least.