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
