Oh, we are supposed to get emails? That would be great!
I keep having to poll harbour for notifications.
Yes, but i wouldn’t have asked if it wasn’t because it had passed QA 3 times with this behaviour, and i assume people will lose their settings now.
But I’ll revert then, no worries… just a bit confused.
No, it deals only with packaging and runtime stuff (afaik).
Having opinions on how the source code is organized would be silly.
You read my mind. 10 years of java development have left deep scars 
I kid. Sort of.
Hi @vige. As I read your blog post about Sailjail today, it is the right time to start experimenting with it, right? It there any draft for the new Harbour rules related to Sailjail? And migration guide?
I’m not setting OrganizationName in desktop file nor Qt code now. It works with Sailjail in SFOS 4.2, but my application is loosing access to ~/.config/<app-name>. When I setup organization name, configuration is mounted from ~/.config/<organization>/<app-name>, that needs migration and organization needs to start with harbour- to comply today’s Harbour rules…
Hi, and thanks for the questions!
Yes, now is the time to start experimenting. Actually, the new Harbour rules are already in place. So you can already submit apps with sandboxing profiles to Harbour, but the profiles won’t have any effect yet. And the organization name does not have to start with harbour 
For those who are better at reading code than English, here’s the commit, defining the new rules: https://github.com/sailfishos/sdk-harbour-rpmvalidator/commit/9988aa5a06ea3d30193e7548a12016d004d4e353
As for migration - yes, we definitely should write some kind of guide. For now, I think the best thing to do is to just move the configuration files from the old directory to the new. It’s easy to do as your applications are not yet sandboxed.
Ok, I will need to write some migration code. It is easy. But when I add this configuration to desktop file:
[X-Sailjail]
Permissions=Internet;Audio;Location;RemovableMedia;Documents;Downloads
OrganizationName=cz.karry.osmscout
ApplicationName=harbour-osmscout
Sailjail refuses it:
[defaultuser@Xperia ~]$ /usr/bin/sailjail -p harbour-osmscout.desktop /usr/bin/harbour-osmscout 2>&1
[sailjail] ERROR: Invalid value harbour-osmscout for ApplicationName
[defaultuser@Xperia ~]$ version
Sailfish OS 4.2.0.21 (Verla)
I may change app name it to OSMScout, but does it comply with Harbour rules? It will not match to HARBOUR_APP_NAME (as used in FAQ) then and it is kind of weird. It is necessary to match with name set by QCoreApplication::setApplicationName ?
Yes, changing the name to OSMScout complies with the Harbour rules. The FAQ needs updating - I’m quite sure we have an open task about that. It is necessary to match the application name set in the code, but then again you don’t have to set it in the code. If you use libsailfishapp (like most Sailfish apps should), it will take care of setting the application name.
TIL: You need to remove X-Nemo-Application-Type=silica-qt5 or it will try (and fail) to boost sailjail itself.
Edit: only when testing with sailjail as the executable.
Thanks for your support. I made simple migration utility (c++/Qt), everyone can use it as inspiration: https://github.com/Karry/osmscout-sailfish/pull/270/commits/c4c4211e2c5f273a306ae5fd58cccbe3fe277e16
@vige I have last remaining issue. When I am using QSettings instance for storing application configuration (created with default constructor), it is using ~/.config/<organizationName>/<appName>.conf file, but Sailjail is creating and whitelisting ~/.config/<organizationName>/<appName> directory. Is there any global possibility to say QSettings to use config file in different directory? Or Sailjail to whitelist specific file?
To me that sounds like a bug, and I filed it as such in our internal bug tracker.
So, I setup organization name (cz.karry.osmscout), prepare code for migration of configuration and new release was rejected, because:
Your application is creating misnamed folder under /home/defaultuser/.cache/cz.karry.osmscout and /home/defaultuser/.config/cz.karry.osmscout and /home/defaultuser/.local/share/cz.karry.osmscout. Folder name must be harbour-osmscout.
We will need some time (at least one application release) when applications will be using new locations, but still be running without sailjail - to make migration possible. Is there any plan when Harbour rules will be updated?
Yes there is. I’m literally working on it right now. I hope we can get the new rules in place within a week. Of course, one should always expect the unexpected, and this is kind of busy week for us, so things might get delayed a bit, but anyway soon™
Is it legal to set Orga name to “.”?
That would work around the problem that most(?) apps don’t use an orga name in their paths, and just have .foo/appname locations.
…and the new rules should be in place now. Please test and report if you still have issues uploading your apps which are using the new locations.
You could make up Org name - it doesn’t have to be something available. Similar issue is with Flathub/Flatpak for example.
Thank you for updating the Harbour FAQ, but the config files are not covered yet. As I wrote previously, QSettings is using ~/.config/<organizationName>/<appName>.conf file, not ~/.config/<organizationName>/<appName> directory.
I somewhat disagree - the config files are covered. It just isn’t mentioned that QSettings by default uses path which isn’t compatible with Harbour rules. I would consider this a bug in QSettings, but we haven’t really decided yet what to do about it. In any case, for the time being, I suggest using QSettings by giving it a full path to the file.
Could you make an official announcement with all those suggestions when this is the time? (when 4.3 is released I suppose)
It would be cool to have a quick FAQ and concrete examples, covering that kind of things:
harbour-myapp)
Taking into account that QSettings have been always using this path, I wouldn’t consider it as a bug and it seems to me that Harbour rules would have to account for it. Not that we can file QT BUG and hope for it to be fixed, right?
Sure thing, will do!