We’ve accumulated a goodly number of bug fixes on the 3.1 branch now, enough that I’d like to release 3.1.19:
4363: When retiring, cancelling side selection leaves side == null
4259: When retiring, ‘Become observer’ fails to update other players’ rosters
4258: Large image masks in Non-Rectangular trait lock up the GUI
4204: Java 7 has incorrect offset for drag images
4184: Should use DocumentListener to catch updates on Swing text fields
4132: Bad layout for Map window obscures Global Key Command buttons
3075: NegativeArraySizeException when snapshotting large maps
Bad tile-counting when snapshotting maps
All of these are rather serious and/or old. When testing, please:
Try retiring and joining sides in various combinations, in order to exercise the code modified for 4259 and 4363.
If you can, check that the ghost offset looks right when dragging pieces. In particular, if you can check this on Windows with both Java 6 and Java 7, please do so. It would also be helpful to hear from someone using a Mac. This will help verify the fix for 4204.
Thanks in particular to Seth Gilchrist for spotting 4184 and 4259, to Lance Leung for fixing 4204, and to George Hayward for fixing 4132.
Tried 3.1.19-svn8131 on MacOS X 10.7.3 with java 1.6.0_31. The drag ghost offset is wrong. Looks like the top/left of the ghost is at the bottom/right of the image dragged.
If you can, check that the ghost offset looks right when dragging
pieces. In particular, if you can check this on Windows with both Java
6 and Java 7, please do so. It would also be helpful to hear from
someone using a Mac. This will help verify the fix for 4204.
Tried 3.1.19-svn8131 on MacOS X 10.7.3 with java 1.6.0_31. The drag
ghost offset is wrong. Looks like the top/left of the ghost is at the
bottom/right of the image dragged.
I’ve committed a fix. Does 3.1.19-svn8137 work for you? (It’s uploading
now, will probalby be finished within the next five minutes.)
The 8137 fixed the drag ghost offset issue. It now looks like it should on my computer.
Two comments that are not related to the drag ghost thing:
Sometimes when you drag there is no ghost at all. This usually happens when events follow each other very fast. Like in the Memoir '44 module when I am building a scenario, I clone a terrain tile piece, and drag it, and clone and drag etc, quite a number of times in succession. For a % of these drags there is no ghost or any feedback of the drag.
The VASSAL application is delivered on the dmg disk image as read only for all. This means whenever I want to do anything with it, for example delete an older copy, I have to enter my administrator password. Other software delivered on dmg’s does not come with this problem.
The 8137 fixed the drag ghost offset issue. It now looks like it should
on my computer.
Thanks for verifying.
Two comments that are not related to the drag ghost thing:
Sometimes when you drag there is no ghost at all. This usually
happens when events follow each other very fast. Like in the Memoir '44
module when I am building a scenario, I clone a terrain tile piece, and
drag it, and clone and drag etc, quite a number of times in succession.
For a % of these drags there is no ghost or any feedback of the drag.
Does this also happen with 3.1.18? My suspicion is that the system can’t
keep up with producing the drag images.
The VASSAL application is delivered on the dmg disk image as read
only for all. This means whenever I want to do anything with it, for
example delete an older copy, I have to enter my administrator password.
Other software delivered on dmg’s does not come with this problem.
To date, we’ve been creating the disk image with genisoimage on Linux.
My guess for why is shows up as read-only is that the filesystem in the
image is ISO9660, not HFS+. I think genisoimage can generate an HFS
(no plus?) filesystem as well, and I seem to have mkfs.hfs and
mkfs.hfsplus, so I might be able to use dd, mkfs, mount, and cp to make
an HFS or HFS+ image.
What would help me do this is to have some idea of what OS X is
expecting, as I have no way to test any of this myself.
The VASSAL application is delivered on the dmg disk image as read
only for all. This means whenever I want to do anything with it, for
example delete an older copy, I have to enter my administrator password.
Other software delivered on dmg’s does not come with this problem.
To date, we’ve been creating the disk image with genisoimage on Linux.
My guess for why is shows up as read-only is that the filesystem in the
image is ISO9660, not HFS+. I think genisoimage can generate an HFS
(no plus?) filesystem as well, and I seem to have mkfs.hfs and
mkfs.hfsplus, so I might be able to use dd, mkfs, mount, and cp to make
an HFS or HFS+ image.
Just to see what it would do, I tried creating an HFS+ image for
3.1.19-svn8137 manually:
Yes, it’s a little better. The disk image works. The old image would mount and then open a new Finder window, this image doesn’t do that, it only mounts. The VASSAL application has the read/write privileges, but it’s locked for some reason (Finder attribute, like the Read Only checkbox on Windows).
Yes, it’s a little better. The disk image works. The old image would
mount and then open a new Finder window, this image doesn’t do that, it
only mounts. The VASSAL application has the read/write privileges, but
it’s locked for some reason (Finder attribute, like the Read Only
checkbox on Windows).
Do you have any suggestions for how I might change that? Is it perhaps
an issue with who owns the files inside the disk image? (If so, what
user should own them?)
The locked attribute is not related to the UNIX style access privileges, nor to the HFS+ ACLs. It is an old style HFS file attribute boolean flag. There must be something during the creation process of the application package or the disk image that sets this attribute, although it’s not related to the disk image itself directly. A disk image can be read-only, but it would not set this attribute on the files contained within.
The locked attribute is not related to the UNIX style access privileges,
nor to the HFS+ ACLs. It is an old style HFS file attribute boolean
flag. There must be something during the creation process of the
application package or the disk image that sets this attribute, although
it’s not related to the disk image itself directly. A disk image can be
read-only, but it would not set this attribute on the files contained
within.
Any idea how I can affect this? The only tool I have which seems
relevant is hattrib, but it refuses to operate on HFS+.
I’m using Mac OS X 10.7.3, with Java 1.6.0_31 (apple build).
I’m still seeing some Mac-only bugs (they don’t seem to appear in windows version):
If I attach a property sheet to a card/piece, and in the property sheet, I add a property with Tick Marks with Value & Max, the boxes that hold the Value and Max do not expand to hold their respective values.
In the Module Library, I left-click on a module to highlight it and then fairly quickly right-click on the same module to select Edit Module (or anything) in the context menu, the module will often Open before I have a chance to make a selection. I’m not sure, but it seems like it’s treating the left-click followed by right-click as a double-click, even though they are with different mouse buttons. The right-click will both open the module and display the context menu, so that single mouse-click is doing 2 different things. I think many or most Mac users are using 2-button mice these days.
In the Module Library, I double-click on a module to open it. The Welcome window appears. If I then select “Cancel” the Welcome window closes, but it leaves open a short,wide " controls" window (with the module name appearing where it says . Shouldn’t my pressing of the cancel button inhibit the appearance of this window, bringing me back to just the Module Library?
Cancelling the welcome dialog opens the module in Windows as well. I
guess I’ve never thought of this as a bug, more an idiosyncracy.
This is not exactly intentional behavior, but fixing this properly
(instead of just removing the Cancel button) would involve reworking
the Welcome wizard, which is not something that’s going to happen
before V4.
I’m using Mac OS X 10.7.3, with Java 1.6.0_31 (apple build).
I’m still seeing some Mac-only bugs (they don’t seem to appear in
windows version):
If I attach a property sheet to a card/piece, and in the property
sheet, I add a property with Tick Marks with Value & Max, the boxes that
hold the Value and Max do not expand to hold their respective values.
In the Module Library, I left-click on a module to highlight it and
then fairly quickly right-click on the same module to select Edit Module
(or anything) in the context menu, the module will often Open before I
have a chance to make a selection. I’m not sure, but it seems like it’s
treating the left-click followed by right-click as a double-click, even
though they are with different mouse buttons. The right-click will both open the module and display the context menu, so that single
mouse-click is doing 2 different things. I think many or most Mac users
are using 2-button mice these days.
I’m using Mac OS X 10.7.3, with Java 1.6.0_31 (apple build).
I’m still seeing some Mac-only bugs (they don’t seem to appear in
windows version):
If I attach a property sheet to a card/piece, and in the
property
sheet, I add a property with Tick Marks with Value & Max, the boxes
that
hold the Value and Max do not expand to hold their respective
values.
In the Module Library, I left-click on a module to highlight it
and
then fairly quickly right-click on the same module to select Edit
Module
(or anything) in the context menu, the module will often Open before
I
have a chance to make a selection. I’m not sure, but it seems like
it’s
treating the left-click followed by right-click as a double-click,
even
though they are with different mouse buttons. The right-click will both open the module and display the context menu, so that single
mouse-click is doing 2 different things. I think many or most Mac
users
are using 2-button mice these days.