This is a conflict between the fact that QSettings stores its file in a shared directory by default and that isolation impose to hide shared directories and use only private directories.
It's also a bit of an issue because the old conf file is not visible from inside the jail and thus running flowplayer inside the jail cannot migrate the user conf file to its new proper location. Jolla thought about this, but it's only working for harbour compliant applications (which was not the case of flowplayer) where the directory naming convention is using the harbour- prefix. So accepting this PR will result in the QSettings file being recreated and the user starting with a "new" flowplayer. The directories to parse for music will be lost for instance and will have to be reset. There is a possibility to migrate the file manually as a postinst rule in the RPM, dealing with the primary user, but that's error prone and ugly (the packkaging system is not the place to do this).
Close #99.
Sailjail is not mounting the generic config dir, so the QSettings file should be under org/app/ dir and not under the org/ dir. See https://forum.sailfishos.org/t/application-data-dir-sailjail-and-organizationname/6471/14 for more details.
This is a conflict between the fact that QSettings stores its file in a shared directory by default and that isolation impose to hide shared directories and use only private directories.
It's also a bit of an issue because the old conf file is not visible from inside the jail and thus running flowplayer inside the jail cannot migrate the user conf file to its new proper location. Jolla thought about this, but it's only working for harbour compliant applications (which was not the case of flowplayer) where the directory naming convention is using the harbour- prefix. So accepting this PR will result in the QSettings file being recreated and the user starting with a "new" flowplayer. The directories to parse for music will be lost for instance and will have to be reset. There is a possibility to migrate the file manually as a
postinstrule in the RPM, dealing with the primary user, but that's error prone and ugly (the packkaging system is not the place to do this).