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:
- The fact that we need to change our app name (or actually, set one, until now it just defaulted to
harbour-myapp)- Also the recommended format for the organizationName
- The fact that the renaming will make all apps losing their cache/config since the paths will change
- Maybe how we can avoid that without asking users to copy the directories manually?
- What exact change do we need to make for this QSettings “bug”
1 Like
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?
3 Likes
Sure thing, will do!
2 Likes
@vige, karry’s statement
contradicts your statement in your blog entry about the firejail-based sandbox implemented for SailfishOS:
with the default profile you will get ~/{.local/share,.config,.cache}/packagename directories mounted inside the sandbox.
I hope I am misunderstanding something, because @karry’s observation means the all applications (which use a ~/{.local/share,.config,.cache}/packagename directory; that is almost every app) will cease to run on SailfishOS ≥ 4.4 without being adapted.
Thus my concern is, if the statement “the default profile will mount ~/{.local/share,.config,.cache}/packagename inside the sandbox” still is conformant to Jolla’s plans / implementation?
@vige, I cannot see that your new thread you are linking to answers @Sthocs’ questions, even though you replied “Sure thing, will do!” and now replied to this post of yours that you “hope this helps”.
Hence answers to @Sthocs’ questions for proper guidance to Jolla’s sandboxing still would be helpful, e.g., if app names with the “harbour” prefix (e.g., harbour-myapp) are technically still feasible when an app has activated the sandboxing (that was rather implicitly asked).
P.S.: It also would be helpful to know if the workaround @nephros suggested is going to be technically prevented or not. Even though that sure is not what you intended, I might be helpful as a quick & dirty workaround for developers who publish their apps at Openrepos or chum and are slow to fully adapt to Jolla’s sandboxing rules.
Side note: For me the intentions for such a fine grained “organisation” directory structure is not fully obvious, especially as it is a 180° turn from the old rules (i.e., every app has to have harbour- prefixed if it is going to be submitted to the Jolla Store, which was definitely more awkward, but one became used to it over the years).
Hi @vige , is everything with Sailjail going as planned? Will be Sailjail enabled in Harbour for community applications after official release SFOS 4.3?
Yes, so far everything is going as planned. But as usual, you can expect a few hiccups in the first few days after the release. So if you have any trouble getting your apps in Harbour, please tell me so I can check if there is anything I can do to help.
1 Like