Here is my proposal and I hope it is not like rewriting MakeHuman because of pathnames
When installing MakeHuman on Linux, a small file in .config (like blender does) is created. This file only consists of the default pathname for the user documents,
For MacOS and Windows there are similar places to put the file, I guess. So we have an initial version and the empty directories are created under the default pathname, same as today. If it is possible to put the request for the pathname in the installer, the user can answer the question directly ... otherwise if the installation should not be changed, he is able to change it later at least.
If the user changes the pathname in this file, he knows what he is doing, Either he copies/moves his assets to the new location or MakeHuman creates the empty structure at the new place again, when he starts the software (in this case he can do the copy afterwards).
The settings.ini should be changed, so that the absolute paths are avoided (although they might be allowed, if the user himself changes them), my proposal is something like
- Code: Select all
"loaddir": @@USERDIR@@/v1/models
Like in Blender, the settings should be saved on demand and not on each time when closing MakeHuman.
When you remove MakeHuman there is no problem. When somebody changed a location, he knows what to delete afterwards. And a file containing a single line in .config? As a Linux guy I had things even worse, like
bla.rpmsave files in /etc/cron.d ... cron tries to start these as well. And when you remove thunderbird under Linux it will hopefully not remove the .thunderbird path in your home directory automatically, otherwise you will loose all your mbox files as well. We should leave the decision what to remove to the user, Of course we can add a few lines of documentation in the Wiki how to remove everything.
An optional parameter for the path is also useful. When we call MakeHuman with this pathname, the small configuration file will
not be parsed. One possibility would be to put this statement with the pathname into a GUI starter (e.g. in xubuntu). But the main advantage for this parameter is to simplify development, because it could be useful to work with an alternative pathname (with less assets etc.).