I need the Program install folder, the Cache folder and plugin folder (and any other program folders to be configurable and changeable…
I can not have any of this in the apps folder and it is not enough to use junction points of hard-links…
The software can be moved to another folder and run from there, so there are no system reasons for not having a possibility to change or set this folders individually.
You should not force people to use predefined folder for either software-, settings-, cache- and data.
This is a really bad practice, even though the some of the Microsoft teams do the same !
Please change this so that it confirm with standard desktop application installations for Windows.
Hi,
the program itself can be installed somewhere else, but this might probably break auto updates. There are CLI options to configure the location of the cache and log folders – we will provide more details on this issue as soon as possible.
I have already moved the softwares install folder and it works, but yes, there are problems with the updates. I wish you could use something with more control as an installer…
We are likely going to switch to NSIS (or provide it in addition to the Squirrel-based packages). Would that be more useful for you?
While providing an NSIS package should be easy to do, switching to NSIS for good, will require a re-write of the auto-update module so this is a change that we’ll have think through in detail before we commit to it. Since we have no avid Windows users on the team at the moment, we’re very grateful for feedback and suggestions of proficient Windows users such as yours!
To change the default user-data, cache, and log folders you can use command line options or environment variables. The user-data includes your local configuration and ontology database; it should be relatively stable in terms of size. The cache folder contains the image-cache for each project (i.e., thumbnails and full-size versions of remote photos or photos which are not natively supported by the platform).
You can see the relevant CLI options in the screenshot below:
Instead of using CLI options you can also set environment variables using the option name with the TROPY_ prefix; e.g., the variable TROPY_DATA would change the user-data folder.
We could consider using registry keys for these settings on Windows, too, if that would help.
I know it can be problematic with Windows in a research enviroment, no problem…
I am not familiar with installers anymore, and whats best, its more than 20 years since I was making network install packages for Windows…
But any solution where you can let the users choose the path of data, the path of installation and the path of software configuration is enough for nearly any scenario…
The path settings is enough, but a ini or json config file would be best, because then you have a full movable application, only thing needed is to reset the path in the file, and there will be no traces of the software other than what Windows allways do…
I did read a little about nsis a while ago, but I can use a some time and see i I can find any pros/cons…
I will give you a feedback…
At the moment the CLI and enviroment settings is enough for me to be able to use the software without to much trouble,… so take your time so that it will work on all systems… I’m not a developer, but I know that there can be a lot of traps when you shall have a system that works on all Operating Systems…
