[QGIS-Developer] Inconsistencies in QGIS ini path

[Tim Sutton]

Hi Richard

Thanks for your reply - see below for inline responses:

On Mon, Aug 17, 2020 at 12:32 PM Richard Duivenvoorde <rdmailings at duif.net>
wrote:

> On 8/17/20 9:23 AM, Tim Sutton wrote:
> >
> > On Sun, Aug 16, 2020 at 11:20 PM Nyall Dawson <nyall.dawson at gmail.com
> <mailto:nyall.dawson at gmail.com>> wrote:
> >
> >     On Sun, 16 Aug 2020 at 18:28, Tim Sutton <tim at kartoza.com <mailto:
> tim at kartoza.com>> wrote:
> >     >
> >     > PopOS Flatpack ini:
> >     >
> >     > <PREFIX>/QGIS/QGIS3/profiles/<PROFILE NAME>/QGIS/QGIS3.ini
> >
> >     > PopOS deb ini:
> >     >
> >     > <PREFIX>/QGIS/QGIS3/profiles/<PROFILE NAME>/QGIS/QGIS3.ini
> >     >
> >     > macOS all in one DMG ini:
> >     >
> >     > <PREFIX>/QGIS3/profiles/<PROFILE NAME>/qgis.org/QGIS3.ini <
> http://qgis.org/QGIS3.ini>
> >     >
> >
> >     These ones are all following the operating system's guidance for
> >     storing local configuration. Is this an issue? I'd expect most of the
> >     configuration inside the user profile to be storing relative paths to
> >     the profile folder, not absolute. If not, do you have examples of
> >     settings which store absolute paths?
>
> Hi Tim,
>
> Only 'difference' I see is between the macOS and the other ones?
>

Correct - I put the two different linux based packages in to show they are
consistent.



> One thing to know it that because of the 'sandboxing' flatpack does not
> store it's stuff in the same place as a Linux distro does (in
> ~/.local/share).
>

Yup




>
> Maybe there is some 'APPLICATION' name in the path's? And that differs on
> macOS dmg's?
> Although:
> https://github.com/qgis/QGIS/blob/master/src/core/qgsapplication.cpp#L204
> looks like it is a Qt thing:
>
>  QStandardPaths::standardLocations( QStandardPaths::AppDataLocation
> ).value( 0 );
>
> With me here (having both my own builds AND flatpaks), running:
>
> QStandardPaths.standardLocations(QStandardPaths.AppDataLocation)
> in the pythonconsole shows:
> [
>  '/home/richard/.local/share/QGIS/QGIS3',
>  '/usr/share/gnome/QGIS/QGIS3',
>  '/home/richard/.local/share/flatpak/exports/share/QGIS/QGIS3',
>  '/var/lib/flatpak/exports/share/QGIS/QGIS3',
>  '/usr/local/share/QGIS/QGIS3',
>  '/usr/share/QGIS/QGIS3'
> ]
>
> Can you test this on a mac?
>

Heheh once you leave mac, you can never go back :-) Hopefully someone
looking in from macOSland on the list here if they can test.



>
> IF it is different, I think it is better to adhere to Qt-standards then to
> build those path's ourselves?
>

Well the issue I am trying to highlight is that the config folder as
currently implemented is not portable. I thought it was part of the design
intent of switching to ini based configs way back that there was a
homogenous system for managing configurations. Currently having <PROFILE
NAME>/qgis.org/QGIS3.ini on a mac and <PROFILE NAME>/QGIS/QGIS3.ini on
linux (curious to know what Windows does) breaks the principle of least
surprise and means that your settings folder isn't portable between
machines when it easily could be,

Regards

Tim




>
> Regards,
>
> Richard Duivenvoorde
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer



-- 
------------------------------------------------------------------------------------------

Tim Sutton
Visit http://kartoza.com to find out about open source:
 * Desktop GIS programming services
 * Geospatial web development
* GIS Training
* Consulting Services
Skype: timlinux Irc: timlinux on #qgis at freenode.net
Tim is a member of the QGIS Project Steering Committee
-------------------------------------------------------------------------------------------
Kartoza is a merger between Linfiniti and Afrispatial
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20200817/ee458730/attachment.html>