QGIS » QGIS Application

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.

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.

so better let's wait for the 2.0

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.

Can we get this moving for 1.7?

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

Patch supplied only deals with WIN32. SInce we Have Win 64 also, is that patch OK for all windows versions?

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

Ok, I don't insist on keeping it open. I'm not a Windows user, so I leave the decision to more competent folks.

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.

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?

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.

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 ?

I guess I can't reopen this... maybe an admin, or bug reporter (Borys)?

I can't either...