It is sometimes annoying to loose one's customized workbench-state.xml just because OpenJUMP has been updated.
Would be nice to have a copy of workbench-state in the user directory (~/.OpenJUMP) and to search the file in this directory first.
Status: open Created: Mon Jan 30, 2017 07:47 AM UTC by michael michaud Last Updated: Mon Jan 30, 2017 07:47 AM UTC Owner: nobody
It is sometimes annoying to loose one's customized workbench-state.xml just because OpenJUMP has been updated.
Would be nice to have a copy of workbench-state in the user directory (~/.OpenJUMP) and to search the file in this directory first.
hey Mike,
the current logic should be.
if OJ is not installed somewhere write only (multi user environment), generally testing if we can write to OJ's folder, then use that
else use the user's home dir.
so if you install OJ under windows to c:\Programs and run it as a non administrative user you should get the behaviour you want.
well, portable software usually is self contained and does not use system profiles for obvious reasons. the famous http://portableapps.com/ packages eg. do it this way.
but i am not fixed on this. let's hear what the others have to say. ..ede
the other advantage of the current way is that incompatibilies introduced in newer versions only hit p
On 30.01.2017 22:21, michael michaud wrote:
Hi ede,
Why should it depend on how OpenJUMP is installed (I usually prefer the portable edition) ?
What I would like is :
- read the user-directory if a workbench-state.xml can be found there
- read the OJ directory in other cases
- write to the user directory if any (and if it's writable)
- write OJ directory in other cases
It seems more simple and it works the samme way for all bundles.
Status: open Created: Mon Jan 30, 2017 07:47 AM UTC by michael michaud Last Updated: Mon Jan 30, 2017 07:47 AM UTC Owner: nobody
It is sometimes annoying to loose one's customized workbench-state.xml just because OpenJUMP has been updated.
Would be nice to have a copy of workbench-state in the user directory (~/.OpenJUMP) and to search the file in this directory first.
I agree it is annoying to loose the WMS addresses and database connections etc. after update. But I also tend to have several OpenJUMP versions installed and having the same workbench-state.xml for all is not optimal either. Think about testing this and that with a new version, I do not really like to change the settings of my good old workhorse version by some random tests. Could it be made selectable?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
there is the concept of having a marker file in the program's folder eg. 'OJ_HOME/.portable', which signals the software to use the folder as settings folder as well.
deleting the marker makes the software use the standard multi user home folders again.
would you guys be in favor of this approach for OJ? ..ede
On 31.01.2017 12:48, Jukka Rahkonen wrote:
I agree it is annoying to loose the WMS addresses and database connections etc. after update. But I also tend to have several OpenJUMP versions installed and having the same workbench-state.xml for all is not optimal either. Think about testing this and that with a new version, I do not really like to change the settings of my good old workhorse version by some random tests. Could it be made selectable?
Status: open Created: Mon Jan 30, 2017 07:47 AM UTC by michael michaud Last Updated: Mon Jan 30, 2017 09:21 PM UTC Owner: nobody
It is sometimes annoying to loose one's customized workbench-state.xml just because OpenJUMP has been updated.
Would be nice to have a copy of workbench-state in the user directory (~/.OpenJUMP) and to search the file in this directory first.
Let me check I understand your proposition :
if /.portable is in the installation folder, OJ uses it. If it is not there, it will look into the user folder ?
Same policy for writing ? If OJ_HOME/.portable is not there, it will write to user directory ?
Seems good to me.
What do you think Jukka ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On 30.01.2017 08:47, michael michaud wrote:
hey Mike,
the current logic should be.
if OJ is not installed somewhere write only (multi user environment), generally testing if we can write to OJ's folder, then use that
else use the user's home dir.
so if you install OJ under windows to c:\Programs and run it as a non administrative user you should get the behaviour you want.
..ede
Related
Feature Requests: #253
Hi ede,
Why should it depend on how OpenJUMP is installed (I usually prefer the portable edition) ?
What I would like is :
It seems more simple and it works the samme way for all bundles.
well, portable software usually is self contained and does not use system profiles for obvious reasons. the famous http://portableapps.com/ packages eg. do it this way.
but i am not fixed on this. let's hear what the others have to say. ..ede
the other advantage of the current way is that incompatibilies introduced in newer versions only hit p
On 30.01.2017 22:21, michael michaud wrote:
Related
Feature Requests: #253
I agree it is annoying to loose the WMS addresses and database connections etc. after update. But I also tend to have several OpenJUMP versions installed and having the same workbench-state.xml for all is not optimal either. Think about testing this and that with a new version, I do not really like to change the settings of my good old workhorse version by some random tests. Could it be made selectable?
there is the concept of having a marker file in the program's folder eg. 'OJ_HOME/.portable', which signals the software to use the folder as settings folder as well.
deleting the marker makes the software use the standard multi user home folders again.
would you guys be in favor of this approach for OJ? ..ede
On 31.01.2017 12:48, Jukka Rahkonen wrote:
Let me check I understand your proposition :
if /.portable is in the installation folder, OJ uses it. If it is not there, it will look into the user folder ?
Same policy for writing ? If OJ_HOME/.portable is not there, it will write to user directory ?
Seems good to me.
What do you think Jukka ?