I thought I would start this up as a branch from the discussion that hijacked a module support thread.
We have been discussing various things related to making the Vassal program be more Mac-like, having a standard double-clickable application, etc.
Some of the items can be easily addressed through the use of Java properties.
One such example is “apple.laf.useScreenMenuBar” to put the menu at the top of the screen.
These can be set in one of two ways:
By using the command line switch -D to set the property value, or for applications that are packaged as Mac .app bundles, through values in the Info.plist file. In Info.plist, one can use the -D switch in the VMOptions key or one can set up a separate set of Property keys.
There are some benefits to either method:
-D in VMOptions
+1: It is a standard Java mechanism.
+2: It can be the same regardless of command line or .app packaging
+3: It can even be included without harm in non-Mac versions, since they just would ignore that particular property
Use the Properties dictionary with sub-keys for each property
+1: It is a bit more organized than including everything on the command line.
+2: It is easier to modify the memory parameters if one doesn’t have to worry about extra properties in the VMOptions key. This is one plan for manipulating the memory sizes.
-1: It requires special handling on the Mac. But since these would be Mac-only and one is already building a .app, that may not be too bad.
I’m inclined toward setting these things from within VASSAL, since
then we can keep them all (for all platforms) in one place. This has
all of the benefits of both methods you mention.
As far a nativization, I found both of these some time ago when I
was researching this. Comments?
Sounds reasonable to me.
I guess the key is to make sure they get set before creating the GUI,
but that’s trivial to arrange.
I’ve read this one and it seems to be quite good, even though it is
about 5 years old.
I just skimmed this and it appears to have some nice tips as well. In
particular, it covers issues with the Dock and names, but if one goes
the route of building native .app versions of Vassal for Mac, it may
be cleaner to handle through Info.plist keys that set the name, etc.
There are a few other minor things, such as some renaming of menu
items. For example, instead of “Edit Preferences…”, the Mac
normally just uses “Preferences…”, which is shorter and has the
additional benefit of making the important word appear first.
That is one of the points I recently read about on Bruce Tognazzini’s
UI site http://www.asktog.com/. It’s a great site and well worth
visiting for anyone who is doing any user interface programming. It
came from http://www.asktog.com/basics/firstPrinciples.html, in the
section on “User Efficiency” which states “Menu and button labels
should have the key word(s) first.” and goes on to contrast two
potential menu designs:
I think a big chunk of nativization has been covered by getting the
single menu bar and the dock icon right, and by putting it in an app
bundle that can be dragged about as a single file.
The menu arrangements mentioned aren’t quite right (eg File, Quit as
well as VASSAL, Quit VASSAL), but it’s not glaring. I’m not sure about
File, Quit doing something different than VASSAL, Quit VASSAL - that’s
worth double-checking. Under what scenarios should quitting be blocked
with some kind of warning now?
I’d say (with my Mac user hat on) that the two priorities, in terms of
going native, would be:
Putting files under ~/Library/Preferences and ~/Library/Application
Data instead of just ~/VASSAL
File associations for double-click on module or log file
Now, I think probably the docs should - assuming I’ve got it right, and
VASSAL just puts the docs under ~/VASSAL/3.0/docs. ISTR being asked
where to install the docs under 2.x, but maybe I’ve just not run a
completely clean install with 3.x
Plug-ins and global extensions should go there too when those happen.
(Also, it’s ~/Library/Application Support, I think I’m getting muddled
with Windows).
There’s also ~/Library/Logs for the log file.
In short, everything that’s in ~/VASSAL today should have a home
somewhere under ~/Library.
In short, everything that’s in ~/VASSAL today should have a home
Is there a typical directory structure that apps use under
~/Library/Application Support? Right now there are probably quite a few
people who have 2.9.9 and some version of 3.0 installed together.
Would you expect to see them under
On Tue, February 5, 2008 9:21 am, Joel Uckelman wrote:
I’ve had a wade through the Apple filesystem guidelines, and their only
guidance is to create a directory with either the application name, or the
company name and then a subdirectory with the application name - after
that it’s up to you.
I’ll have a look when I have a chance at home how any other software
handles it, but my gut feeling is for:
I don’t think a directory for each individual version is a good fit -
otherwise you could end up with 18 versions (so far) of the 3.0 reference
manual!
Hmm. I assume that you’d remove the directories for versions you’re no
longer using. With the drive capacity that machines have these days, I
doubt anyone would even notice having a hundred copies of the reference
manual.
Well, yeah, it’s not about space, just being tidy / polished.
I don’t think you can expect the average user to clean up for the x.y.z
to x.y.z+1 upgrades - ~/Library is a lot like C:\Windows*, or the
registry. Stuff goes in, but unless the app cleans up behind itself, it
never comes out again…