Re: [SailfishDevel] app OrganizationName and harbour
On Saturday 05 April 2014 18:02 Kaj-Michael Lang wrote: Hi Got denied application update as I set my org name properly with app-setOrganizationName() but that lead to a application update rejection as then the path given from QStandardPaths::writableLocation(QStandardPaths::CacheLocation) is not in the format harbour likes. After much digging and finally looking into SailfishApp sources it seems that I'm not even supposed to set the orgname myself, as it sets, unlogicaly, the orgname to appname, and in my mind that feels a a bit strange. Anyway, this took a while for me to find out and it is not mentioned in the harbour FAQ, might be good to add it. This sounds to me like yet another example of the consequences of moving from the reverse FQDN to the 'harbour-*' prefix. I have ranted about this decision before; it really seemed like a rushed let's ship this decision which ends up biting you in your behind on so many unforeseen areas. People are talking about banning apps with 'harbour-*' prefix, and the original issue that it's a first to the mill approach. -- Med venlig hilsen / Best Regards Thomas Tanghus ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] app OrganizationName and harbour
On 05 Apr 2014, at 17:27, Thomas Tanghus tho...@tanghus.net wrote: On Saturday 05 April 2014 18:02 Kaj-Michael Lang wrote: Got denied application update as I set my org name properly with app-setOrganizationName() but that lead to a application update rejection as then the path given from QStandardPaths::writableLocation(QStandardPaths::CacheLocation) is not in the format harbour likes. After much digging and finally looking into SailfishApp sources it seems that I'm not even supposed to set the orgname myself, as it sets, unlogicaly, the orgname to appname, and in my mind that feels a a bit strange. The reason for this is that Qt uses the organization name in some places to determine data store paths (e.g. cache location). The reasons why we want to use XDG are described in some places in the FAQ already, most notably the fact that the system will eventually be able to backup, restore, measure (as in space usage) and cleanup application data. If the organization name is set manually, some of these QStandardPaths locations will not appear in the right place of the XDG hierarchy (with our added $APPNAME requirement). Anyway, this took a while for me to find out and it is not mentioned in the harbour FAQ, might be good to add it. Sure, it can be added; it basically boils down to “don’t set the organization name, application name or organization domain, as these are set by libsailfishapp (and if not using libsailfishapp, all three of them should be set to $APPNAME). Would that work for you as a FAQ entry? This sounds to me like yet another example of the consequences of moving from the reverse FQDN to the 'harbour-*' prefix. I have ranted about this decision before; it really seemed like a rushed let's ship this decision which ends up biting you in your behind on so many unforeseen areas. People are talking about banning apps with 'harbour-*' prefix, and the original issue that it's a first to the mill approach. It doesn’t really have anything to do with “harbour-“ vs. FQDN; even if we were using reverse-FQDNs, the organization name would still have to be set to that $APPNAME. I personally would have bikeshedded for FQDNs (and initially had the same concerns about the harbour- prefix), but that doesn’t work because Qt Creator doesn’t allow dots in project names: https://qt.gitorious.org/qt-creator/qt-creator/source/c9f2ca836886fda40c2508e82f6580487b35f314:src/libs/utils/projectnamevalidatinglineedit.cpp#L46 To quote directly from there: // We don't want dots in the directory name for some legacy Windows // reason. Since we are cross-platform, we generally disallow it. So yeah, the 1990s called and want their directory name restrictions back - and that is the reason why a non-dotted naming scheme was chosen, and a prefix used for namespacing instead (having a separate RPMDB for third party apps or a separate package system would of course also be a possibility, but you can’t just pull that out of thin air, so of course time pressure was also a factor there). In the end, I’m now very content with the “harbour-“ prefix, it lets you immediately spot third party app data in your $HOME by “find”ing harbour-* directories, and on the command line, typing harbour-tab lists all third party apps, plus “rpm -qa | grep ^harbour-“ lists all installed third party RPMs, grep for “harbour-“ in the process list, etc, etc… (this wouldn’t have been possible in such a convenient way with FQDNs). HTH :) Thomas ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] app OrganizationName and harbour
On Saturday 05 April 2014 17:57 Thomas Perl wrote: So yeah, the 1990s called and want their directory name restrictions back - and that is the reason why a non-dotted naming scheme was chosen, and a prefix used for namespacing instead (having a separate RPMDB for third party apps or a separate package system would of course also be a possibility, but you can’t just pull that out of thin air, so of course time pressure was also a factor there). In the end, I’m now very content with the “harbour-“ prefix, it lets you immediately spot third party app data in your $HOME by “find”ing harbour-* directories, and on the command line, typing harbour-tab lists all third party apps, plus “rpm -qa | grep ^harbour-“ lists all installed third party RPMs, grep for “harbour-“ in the process list, etc, etc… (this wouldn’t have been possible in such a convenient way with FQDNs). I realize it's not up for discussion at this point, but I must admit that I find the argumentation to be ... questionable, so I'll vent my frustrations nonetheless. Qt is - as far as I understand - much more open for changes nowadays, otherwise KDE Frameworks 5 wouldn't have dropped so many of their own implementations that they have now gotten integrated in Qt. I'm pretty confident they would be open for stepping into the current millennium regarding directory naming, and process table grepping/tab-expansion is hardly an argument for implementing a naming scheme which I consider fundamentally flawed. Directory path resolving for cleaning up is of course an issue, and XDG compliance is a must, but that should be fairly easily solved by enforcing the naming scheme - as it is now, just not very cleverly. I don't know much (anything) about android apps, but they seem to have a well defined policy for this. I addressed this in[1] with no response; probably because I only saw that thread after the decision had been enforced. As usual a disclaimer: I know next to nothing about packaging, and I'm just an amateur and not very skilled coder. In fact this is the first time I'm made mobile apps (counting out WAP eons ago). [1] https://lists.sailfishos.org/pipermail/devel/2013-November/001523.html -- Med venlig hilsen / Best Regards Thomas Tanghus ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] app OrganizationName and harbour
if appname/orgname is unset manually i'm getting those values by QStandardPaths: /home/nemo/.cache/$APPNAME/$APPNAME - for cache /home/nemo/.local/share/$APPNAME/$APPNAME - for data is it okay? 05.04.2014 21:57, Thomas Perl пишет: On 05 Apr 2014, at 17:27, Thomas Tanghus tho...@tanghus.net wrote: On Saturday 05 April 2014 18:02 Kaj-Michael Lang wrote: Got denied application update as I set my org name properly with app-setOrganizationName() but that lead to a application update rejection as then the path given from QStandardPaths::writableLocation(QStandardPaths::CacheLocation) is not in the format harbour likes. After much digging and finally looking into SailfishApp sources it seems that I'm not even supposed to set the orgname myself, as it sets, unlogicaly, the orgname to appname, and in my mind that feels a a bit strange. The reason for this is that Qt uses the organization name in some places to determine data store paths (e.g. cache location). The reasons why we want to use XDG are described in some places in the FAQ already, most notably the fact that the system will eventually be able to backup, restore, measure (as in space usage) and cleanup application data. If the organization name is set manually, some of these QStandardPaths locations will not appear in the right place of the XDG hierarchy (with our added $APPNAME requirement). Anyway, this took a while for me to find out and it is not mentioned in the harbour FAQ, might be good to add it. Sure, it can be added; it basically boils down to “don’t set the organization name, application name or organization domain, as these are set by libsailfishapp (and if not using libsailfishapp, all three of them should be set to $APPNAME). Would that work for you as a FAQ entry? This sounds to me like yet another example of the consequences of moving from the reverse FQDN to the 'harbour-*' prefix. I have ranted about this decision before; it really seemed like a rushed let's ship this decision which ends up biting you in your behind on so many unforeseen areas. People are talking about banning apps with 'harbour-*' prefix, and the original issue that it's a first to the mill approach. It doesn’t really have anything to do with “harbour-“ vs. FQDN; even if we were using reverse-FQDNs, the organization name would still have to be set to that $APPNAME. I personally would have bikeshedded for FQDNs (and initially had the same concerns about the harbour- prefix), but that doesn’t work because Qt Creator doesn’t allow dots in project names: https://qt.gitorious.org/qt-creator/qt-creator/source/c9f2ca836886fda40c2508e82f6580487b35f314:src/libs/utils/projectnamevalidatinglineedit.cpp#L46 To quote directly from there: // We don't want dots in the directory name for some legacy Windows // reason. Since we are cross-platform, we generally disallow it. So yeah, the 1990s called and want their directory name restrictions back - and that is the reason why a non-dotted naming scheme was chosen, and a prefix used for namespacing instead (having a separate RPMDB for third party apps or a separate package system would of course also be a possibility, but you can’t just pull that out of thin air, so of course time pressure was also a factor there). In the end, I’m now very content with the “harbour-“ prefix, it lets you immediately spot third party app data in your $HOME by “find”ing harbour-* directories, and on the command line, typing harbour-tab lists all third party apps, plus “rpm -qa | grep ^harbour-“ lists all installed third party RPMs, grep for “harbour-“ in the process list, etc, etc… (this wouldn’t have been possible in such a convenient way with FQDNs). HTH :) Thomas ___ SailfishOS.org Devel mailing list ___ SailfishOS.org Devel mailing list
