Here is a list of what tasks should be completed before we put out
3.1.0-beta1. In addition to a few decisions which need to be made, I’m
listing bugs which do not exist in 3.0.18, because it doesn’t make sense
to me to burden our beta testers with bugs of which we are already aware.
-
The main app window doesn’t have focus after the splash screen
disappears, on Windows. (I don’t know how to fix this.) -
Prefs: “use null to view stacks” should be “Use CTRL-Space to view stacks”
Rodney says: The fact that it’s showing ‘null’ probably means there’s a
key missing from the i18n properties file. -
Bad splitter positioning when the Welcome Wizard is enabled.
-
Need to show a dialog to get username/password when VASSAL has none
and Welcome Wizard is off. -
The Zoomer needs input validation for its Configurers.
-
Directory structure in installs: Extensions and plugins one one hand,
and a Mac-specific bundle on the other make it important that we make a
decision about the locations of installed files.
First, about the Mac bundle: I’ve been having a long-running discussion
here (vassalengine.org/forums/viewtopic.php?t=246) and here
(vassalengine.org/forums/viewtopic.php?t=272) with Thomas and Tim F
about building Mac bundles and making VASSAL look more native on OSX. The
upshot is that the standard way of deploying apps is as a DMG (disk image),
which is just a file containing a HFS+ filesystem. It’s not usual for users
to poke around inside these disk images—they just click on them to run
the app inside. The usual place for additional stuff is under
~/Library/Application Support—which is not in the DMG file. Hold that
thought.
Plugins and extensions need to be stored somewhere.
-
If plugin/ and ext/ are expected to be under the base install directory,
then Mac users will never find them, since, as mentioned above, it’s not
typical to look inside disk images. Secondly, I don’t know whether OS X
can resize disk images on the fly—when I create them on Linux, they have
a fixed size, so the might not be any space to add plugins and extensions
later. -
A more general problem is that if extensions or plugins are loaded
automatically, then it becomes important that they not be in ~/VASSAL/ext
or ~/VASSAL/plugin, because then it would be impossible to have different
plugins with different versions of VASSAL.
So, here’s what I’m proposing we do for 3.1:
For the Mac bundle:
The DMG file houses all of the standard JARs and startup scripts.
~/Library/Application Support/VASSAL is the base directory for all VASSAL
stuff not housed in a DMG. Under that, we have a directory for each
installed version of VASSAL, containing plugin/, ext/ and user prefs.
For the Windows installer:
Right now, I’m messing with NSIS, which is a simple installer builder for
Windows programs. We’ll be able to have icons placed on the desktop, a
start menu entry, and a standard uninstaller this way.
Here, I’m proposing that it install VASSAL to
Program Files/VASSAL/VASSAL-x.y.z, which I take it is is the standard
thing to do on Windows, and keep other material in… I’m not sure where,
maybe under ~/Application Data/VASSAL/VASSAL-x.y.z?
For the all-platform zip archive:
The standard zip should have plugin/ and ext/ directories in it, or
should look for them under ~/VASSAL/VASSAL-x.y.z.
I’m not certain on this point yet—but we’re going to have problems if
we don’t sort this out.
Are there any other things which need doing before we put out 3.1.0-beta1?
Just checking.