On 10.03.2013 19:54, Michaël Michaud wrote:
> 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?
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.
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.
> 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
