Ok, that didn’t last long.
Another Release Candidate. I fixed one bug and added some additional stuff Peer wanted to look at.
Why is it so “difficult” to do a “native packaged” version?
Actually the native packaging is just one “switch” in the Netbeans GUI – not much to do here. What I am trying to do – and where there might still be a couple of bugs – I want Vide to behave like it did before!
The changes that I had to implement are about the same changes I did last year, when I changed Vide to be “startable” from everywhere.
See, as I said – the home directory of a Java application is ALWAYS the directory Java was started from. Now Java is started not from the “Vide” directory anymore but from a subdirectory (Vide.app – or even a directory or two deeper).
All settings, all file associations, all project data within Vide are kept as “relative” paths. The base of these relative path information used to be the Java start directory (I will call that from now on “Java_home”) – but now the base of the relative paths must be the directory all these Vide directories reside in (which I will call from now on “Vide_home”).
Relative paths as configuration entities are “good” because we can move Vide around or copy project files to another Vide instance or similar things. This I deemed “good” because it is very “easy” for the user.
But I had to change every file access within Vide – again!
A simple vectorlist load used to be:
String filename = "Vectorlistname.xml";
String path = "xml/vectorlists/"
File f = new File(path+filename);
etc. as you see the File was “created” with relative path information.
Loading the file with above code succeded because the relative path would access the correct directory – the one where Vide was started from. Now I must make sure the above “path” is accessed from Vide_home not from Java_home. In order for that to succeed I must convert the relative path to an absolut path, and this conversion must result in the correct directory.
The “bad” thing with that is, even when I do a:
String here = f.getAbsolutePath();
It does not help all that much, since that is the absolut path to the “Java_home”.
To remedy I have created 4 additional functions:
- String makeVideRelative(String fullpath) – which takes a full path and builds a Vide_home relative path from it
- String makeJavaRelative(String fullpath) – which takes a full path and builds Java_home relative path from it
- String makeJavaAbsolute(String relName) – which actually is more or less the f.getAbsolutPath(), it takes the given relative path and builds an absolut path
- String makeVideAbsolute(String relName) – which takes a given relative path and builds an absolut path, but assumes the given path was relative to Vide_home, not to Java_home
What follows is, that I now must do all file accesses using absolut paths (which are mostly the result of “makeVideAbsolute(String relName)“. These were 100dreds of changes – and I am not certain I got them all, or if I accidently mangled some relative and absolut paths. This is why I chose to do a Release Candidate, in the hopes some people may test this – and report errors (or correct workings).
Release Candidate downloads
Not available. A new vide “full” version is available (or will be shortly).