LateralGM uses its working directory (workdir) for a number of things. This working directory is generated at runtime using two factors: the Java current working directory (which depends on what directory you ran Java from), and the JAR file location. Because both of these locations can be volatile each time you run LateralGM, we're working on ways to refactor out this working directory dependency.
The exact code LGM uses to fetch the working directory is as follows:
- Libraries - the default locations for libraries is set up by the Workdir. These locations, however, are stored in a properties file and can be changed, overridden, or modified as a Setting by the user.
- Keywords for syntax highlighting (not entirely sure why this isn't internalized. This may just be some residual code that never got refactored)
The Plugin also uses a working directory, defined as follows:
Note that because of this, when using the Plugin, LateralGM and ENIGMA cannot be separated into different directories.
It is used for the following purposes:
- The working directory for the Execute Callback, in the Callback toolkit passed to ENIGMA
- Locates Compilers by finding ey files in Compilers/
- Locates API systems by finding ey files in ENIGMAsystem/SHELL/*_Systems
- Locates Extensions by finding ey files in ENIGMAsystem/SHELL/Universal_System/Extensions/
- Reads WORKDIR/settings.h to determine what ENIMGA settings are available, which in turn populates the Settings panel.
- Stores the contents of Definitions between runs at WORKDIR/definitions.h
The workdir would probably be refactored on a use-by-use basis. This is especially effective because it means we can start refactoring individual uses out immediately without worrying about how this affects other uses. All we need to consider is where do they belong, and how to access that location.
It is essential that LateralGM remain cross-platform, and it should be able to run on platforms that we haven't thought of. We should not write individual behaviors for individual platforms for two reasons:
- There may be a platform that we didn't account for, which should otherwise work, but now breaks only because we didn't provide a case for it.
- Identifying individual platforms is difficult and tedious in Java, or else it requires an additional library, which goes against the standalone nature of LateralGM.
Inside the Jar
This option has pretty much been expended - it's highly unlikely that any of the use cases would end up in here, or else they would have already been put in here.
Outside the Jar
This is the current method - the one we're trying to refactor away from.
A good way to obtain system-dependent information on a platform-independent way is to use System.getProperty. A list of available properties is here and a more extensive list here. Notably, this grants us access to the following directories:
- java.class.path - The ClassPath
- java.home - Where Java is installed
- user.dir - User working directory
- user.home - User home directory (~ on linux)
Any of these can be turned into a "File" for Java to then navigate in, however we should be very careful about making assumptions about any directory structure from there.
Temp is also available for us, using a different method, although it is unlikely to be useful in these cases.
Properties are a great system-independent way to store preferences, settings, and properties. On Windows, this is usually the Registry, to give you an idea of what it's for. While we cannot store entire files in here, we can use this to store file and directory locations. This is a great way to allow the user to alter or install locations/files, but it doesn't provide for a default setting other than none/unset.
When in doubt, ask for directions on first run. Unfortunately, this could easily mean the user gets swamped by questions on the first run.
We can place a properties file inside the jar which contains default paths. The user can changed these values, or, more likely, override them or change them in Settings. This method is already utilized by Libraries, as well as the external resource editors.