Hi,
> still user.dir wouldn't be appropriate as this is set by the system.
> better use the delivered jump.home of the startup script or even
> better, detect it like it is done in PluginManager. still not saying
> it should be mentioned on info tab, but i see your point.
>>>> Sorry, my understanding of where user.dir, JUMP_HOME and plugin manager
>>>> point to is not sufficient.
>>>> user.dir seemed OK to me because it is where new File(".") is located in
>>>> a java program or a script.
>>>> Let me know how other variables are different and why they would be better.
>>> just ran a snapshot from my desktop and had the following result (see
>>> attached screenshot)
>>>
>>> OJ in D:\_Desktop\OpenJUMP-20130310-r3313-CORE
>>> user.dir is D:\_Desktop
>> Oh ! I see.
>> Just checked that I've not the same user.dir if I start from .bat or from
>> .exe.
>> How do you explain ?
> the working dir is merely a value given to the software running by the
> operating system. e.g.
>
> you open a terminal, change dir to c:\, now you run
> full\path\to\OJ\bin\start.bat
> guess what your working dir is, right it is c:\ .. seen?
OK
Note : checked that user.dir give the same result from .bat and .exe
(don't know how I found something different before)
Also found a more interesting use case.
You want to open OpenJUMP with a project
oj_windows.bat -project data/myproject.jmp
What relative path must I use ?
myproject.jmp ? data/myproject.jmp ? ../data/myproject.jmp ?
I think working dir give you the starting point
> now it get's complicated. because, to circumvent problematic handling of long
> absolute path names the startup scripts changedir into the OJ folder and all
> path values from there on are given relative. so actually, theoretically your
> approach should work, although it wouldn't for every java app, just OJ as the
> start scripts work that way.
>
> why it doesn't though is not completely clear to me (didn't write windows nor
> jre).
>
> in conclusion: user.dir is not the applications folder. our case is the
> famous exception of the rule.
>
>> Still think that user.dir is the best indicator of where your program is,
>> but I'm no more sure.
> no, it isn't.. what you can do is ask a class where it is located
> class.getProtectionDomain().getCodeSource().getLocation()
> should return the class/jar url of the class and you can create an absolute
> location from there.
OK, I see your point now. The dir where the program is "started from"
and the dir where the jar is "located" are two different things.
So giving the working directory don't say where the program is and
giving the program location does not say where relative paths start from
:-\
Still again, I think that for a normal OJ installation, working dir is
enough (it was what I had in mind at the first place even if I wrote
also about the program location), but I agree that the information is
not as valuable as I thought and it maybe misleading.
Let's see if other users have an opinion (I'm afraid that the topic is
too boring to get feedback).
> NOTE: i saw that your formatting routine did not account for forward slashes
> or other path separators. maybe you might want to use "path.separator" system
> property for that instead.
Good catch, thanks.
Michaël
>
>> Is D:\_Desktop\OpenJUMP-20130310-r3313-COREthe JUMP_HOME of the bat in your
>> example ?
> yes it is.
>
>>> so if you really want to show where OJ is located user.dir is not what you
>>> want. it really only shows the working dir at the moment OJ was started. so
>>> it is also no use to show a current working dir as each filechooser
>>> remebers it's own last dir during OJ run time.
>> As you talk about that, I noticed that not all JFileChooser remember the
>> last used directory, but I do not remember which are missing. Have make a
>> bug report next time.
> should be a fast hack as remembering is done by simply keeping the
> filechoosers over runtime. or do you mean after application restart?
>
> ..ede
>
>> Michaël
>>> ..ede
>>>
> ------------------------------------------------------------------------------
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> endpoint security space. For insight on selecting the right partner to
> tackle endpoint security challenges, access the full report.
> http://p.sf.net/sfu/symantec-dev2dev
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
