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
