Feature request #1442
system specific location of qgis settings
Status: | Closed | ||
---|---|---|---|
Priority: | High | ||
Assignee: | - | ||
Category: | Build/Install | ||
Pull Request or Patch supplied: | Yes | Resolution: | |
Easy fix?: | No | Copied to github as #: | 11502 |
Description
The qgis QSettings are stored in the system location, while the sqlite & plugin directory is always ~/.qgis
. Shouldn't we consider the use of a system-specific location? For example ~\\Application Data\\qgis
in Windows XP
Related issues
History
#1 Updated by Borys Jurgiel almost 16 years ago
I believe it's a bad idea to move the database and plugin directory between 1.0.0 and 1.0.1. It will leave the abandoned directory and lost a part of settings. Users will be just confused and annoyed after upgrading to 1.0.1... So I'd rather prefer to force this change right now and save the future consistency.
#2 Updated by Marco Hugentobler almost 16 years ago
I think it is even worse to move it so short before release. We don't have time to react if there is any unexpected problem. In my opinion, changes like this should be done before feature freeze.
#3 Updated by Borys Jurgiel almost 15 years ago
so better let's wait for the 2.0
#4 Updated by William Kyngesburye about 14 years ago
What about doing this for one of the 1.x releases, maybe 1.6?
Also, add a case for OS X:
#elif defined Q_WS_MAC return QDir::homePath() + QString( "/Library/Application Support/QGIS/" );
I'm not sure if there is a variable for that path fragment or full path like for Windows, but as far as I know it's hardwired in the system as a standard folder as is never localized.
Note also that there is now a runtime switch to set the settings dir, 19506e9c (SVN r13952), so this patch will have to be changed a bit to fit in with that.
#5 Updated by William Kyngesburye almost 14 years ago
Can we get this moving for 1.7?
#6 Updated by William Kyngesburye over 13 years ago
- Target version changed from Version 1.7.0 to Version 2.0.0
- Priority changed from Low to Normal
OK, so not for 1.7.
2.0 it is then...?
#7 Updated by Jürgen Fischer almost 13 years ago
- Pull Request or Patch supplied set to No
- Assignee deleted (
Jürgen Fischer)
#8 Updated by Giovanni Manghi almost 13 years ago
- Pull Request or Patch supplied changed from No to Yes
#9 Updated by Regis Haubourg over 12 years ago
Hi all,
my admin sys asks me to deport .qgis under Application Data to comply with Windows profile replication tools.. (aargh 1.7.4 deployed, so .qgis is just above that directory.. ). has Jürgen patch been applied on trunk?
Any idea if backporting to 1.8 is complicated or risky? Any workaround waiting for this ?
Régis
#10 Updated by Regis Haubourg about 12 years ago
Patch supplied only deals with WIN32. SInce we Have Win 64 also, is that patch OK for all windows versions?
#11 Updated by Pirmin Kalberer about 12 years ago
- Target version changed from Version 2.0.0 to Future Release - Nice to have
#12 Updated by Regis Haubourg almost 12 years ago
Hello all,
since startup option --configpath seems to have been consolidated in 1.9, maybe we can close the demand.
We could add a note in documentation dedicated to system administrators to explain clearly that possibility of moving profiles away from default location.
On the other hand, there remains bug in Qt to get AppData path correctly in Windows. And Windows specs are not really public. So changing default behaviour in QGIS could generate more issues than it could solve.
So I suggest closing the issue if everybody agrees.
Régis
#13 Updated by Borys Jurgiel almost 12 years ago
Ok, I don't insist on keeping it open. I'm not a Windows user, so I leave the decision to more competent folks.
#14 Updated by Jürgen Fischer almost 12 years ago
- Status changed from Open to Closed
- Resolution set to wontfix
#15 Updated by William Kyngesburye almost 12 years ago
I don't agree with closing it. The --configpath startup flag is not a usable solution on OS X since that requires starting from a Terminal, I don't think there is a way to add flags to the startup of an app started in the normal way. The desired config path must be defined as the default in compilation.
#16 Updated by Regis Haubourg almost 12 years ago
Hi all,
I found a good reason to reopen this ticket too. I have directories like '/sextante' and '.maptplotlib' too! We really need to centralize all profile info, caches and other preferences under .qgis. This should be explained as a rule for plugin developpement. Sextante is a particular case, since it now is part of qgis core. We really need to move it somewhere inside .qgis. I will open a ticket for sextante, but we need to solve it here IMHO.
Thoughts?
#17 Updated by William Kyngesburye almost 12 years ago
Not quite the same thing - this ticket is about moving the .qgis folder, not what's in it.
Also, I think that moving .matplotlib files into .qgis is not something we should do since matplotlib is external to QGIS. It would only make sense if matplotlib was bundled in the application package on OS X or Windows, but it's such a useful package independent of QGIS and readily available for all platforms I don't see any reason to bundle it.
#18 Updated by Regis Haubourg almost 12 years ago
I understand you quite well William from a dev point of view. I meant that profile location for qgis uses is not closed at all, we should reopen it.
Please put yourself not as a developper but as a system administrator with 300 users profiles to handle, and qgis is the only app writing so much things everywhere. How serious will look QGIS if we have to cheat the system for each for each sub library or tool driven from qgis. I don't want to create symbolic links for each new library used by a plugin. There is no way to know them in advance and there is a serious risk of data loss.
I didn't test with --configpath option, but does matplotlib or sextante move their profiles in the configpath directory ?
#19 Updated by William Kyngesburye almost 12 years ago
- Target version changed from Future Release - Nice to have to Version 2.0.0
- Priority changed from Normal to High
- Resolution deleted (
wontfix)
Been meaning to reopen this. I think this is very important, especially on OS X. As I've said before, --configpath is not a solution since apps are not started from a Terminal on OS X. The config path needs to be compiled into QGIS.
What files are put in the configpath is another matter, for another bug report if needed.
#20 Updated by William Kyngesburye almost 12 years ago
I guess I can't reopen this... maybe an admin, or bug reporter (Borys)?
#21 Updated by Borys Jurgiel almost 12 years ago
I can't either...