Right now, the behavior is, that each individual build keeps their individual workspace where it is installed. However, we do not have a mechanism to prompt the user to reuse an existing workspace.
1) This could be done by keeping a central registry of any JCT workspaces used on the hard drive (e.g. ~/Documents/.jcryptool/instances), and if detected that the current build is starting for the first time [1], 1a) ask the user to restart the application with that -data flag and 1b) keep a choice of whether that should be permanent.
2) This all could be easier, if we could hook into the workspace selection process other than the earliest-of-early -data flag (no Java can be involved here as it is before the JRE starts). [2]
Eclipse workspace builds, by default, follow the same settings that built JCT products are configured with. This leads, on my machine, to JCT starting up every time with the initial layout of the perspective, which is annoying. However, the run configurations can be changed (green play button -> Run configurations...).
[1]
use the org.eclipse.ui.startup extension point, and write into the workspace a file that indicates this.
Until https://github.com/jcryptool/core/commit/6114c99196cb52d5b26383c2a51f00dc9640c38e, -data directories were shared between installations, which caused confusion for many users.
Right now, the behavior is, that each individual build keeps their individual workspace where it is installed. However, we do not have a mechanism to prompt the user to reuse an existing workspace.
Eclipse workspace builds, by default, follow the same settings that built JCT products are configured with. This leads, on my machine, to JCT starting up every time with the initial layout of the perspective, which is annoying. However, the run configurations can be changed (green play button -> Run configurations...).
[1]
[2] https://www.vogella.com/tutorials/EclipsePreferences/article.html#setting-the-workspace-location-programmatically descripbes a way to set the location programmatically but only with e4 injection. If the e3 equivalent exists (haven't found it) then we can do this properly, detecting workspace vs. real builds and acting appropriately.