Portable Application

Logged In: YES
user_id=168045

In a portable version, the user must be able to select the
location of the config files... either on the same medium as
the app (if writable, eg flash disk) or on the hard drive of
the host computer (if own media is unwritable, eg CD-ROM),
so that the user can easily grab the config files if he had
made changed that he wouldn't like to lose.

Logged In: YES
user_id=915082

What do you think keeps translators from putting their OmegaT folder on a
USB stick and carry it around ?

Would you have specific requirements in mind ?

Logged In: YES
user_id=545103

What's keeping them, is that the configuration files are in
a different location than the application files. This is
because multiple users may use the same install (obviously
on the same machine).

What we could do is make the config dir configurable,
perhaps as a command line option.

Logged In: YES
user_id=915082

ok, then we need to implement 1467150 first (conf files project specific).

For the record, the winPenPack is making a portable version of OmegaT:
http://www.winpenpack.com/main/download.php?view.1083

Didier

Now that we can specify a config dir on the command line, what is missing?

Didier

The comfort of having a default setting that points at the "portable" config folder.
Forcing the portable users to use the command line is not friendly :)

Would an "OmegaT Portable.bat" (and an "OmegaT portable" for Linux/Mac) containing
start java -jar OmegaT.jar config-dir=.
be enough to qualify as a portable application, then?

Didier

The problem with a script is that on OSX (I don't know for Linux) it must first be made executable with chmod.
People who can do that don't have problems working with the command line.
Plus, is OSX users use the Mac package, it won't be trivial to start from the command line.

I'm thinking more about a way to make OmegaT remember the configuration path so that it can be launched with a double click.

Since quite a time now (1.7.3 I think), the Linux script is directly executable, so there's no need to do a chmod anymore (under Linux).

Didier

Ok, so the only issue that remains is OSX.

Basically, all the Java VM parameters (memory etc) are fed from a file inside the package (info.plist).
I am not sure it is possible but maybe setting a parameter there could solve the issue. Problem is the parameter we discuss is not a JVM parameter but an "internal" one...