Re-visiting this with 3.3.0-svn9360, I find a difference with the image produced, compared to v3.2.17 which I missed when I tested previously. Though the image is captured in full, it is somehow scaled wrong in the output compared with v3.2.17.
3.3.0-svn9354 on MacBook Pro (with Retina) MacOS Catalina 10.15.4
Updated:-
…
zoom bug when using the “saved map as PNG file” - confirming, fixed.
Re-visiting this with 3.3.0-svn9360, I find a difference with the image
produced, compared to v3.2.17 which I missed when I tested previously.
Though the image is captured in full, it is somehow scaled wrong in the
output compared with v3.2.17.
Is there any chance that for 3.3 you’d be willing to add the following line to each of the three MouseWheelEvent listeners (last three methods) in ScrollPane.java:
if (e.isControlDown() || e.isAltDown()) return;
Reason – I’m dying to add some MouseWheel functionality in custom java classes, but alas the MouseWheel stuff is attached deep in the bowels of Map.java (no easy way to “override”), and it presently sucks up all the MouseWheel oxygen.
With that line, Ctrl+MouseWheel and Alt+MouseWheel would become available for custom-classing, without altering behavior for present modules.
Full code w/ proposed patch below.
Fingers crossed,
Brian
viewport.addMouseWheelListener(new MouseWheelListener() {
public void mouseWheelMoved(MouseWheelEvent e) {
if (e.getScrollAmount() == 0) return;
if (e.isControlDown() || e.isAltDown()) return; //BR//
if (e.getScrollType() == MouseWheelEvent.WHEEL_UNIT_SCROLL) {
final JScrollBar bar = e.isShiftDown() ?
horizontalScrollBar : verticalScrollBar;
if (bar == null || !bar.isVisible()) return;
bar.setValue(
bar.getValue() +
e.getUnitsToScroll() *
bar.getUnitIncrement()
);
}
}
});
verticalScrollBar.addMouseWheelListener(new MouseWheelListener() {
public void mouseWheelMoved(MouseWheelEvent e) {
if (e.getScrollAmount() == 0) return;
if (e.isControlDown() || e.isAltDown()) return; //BR//
if (e.getScrollType() == MouseWheelEvent.WHEEL_UNIT_SCROLL) {
verticalScrollBar.setValue(
verticalScrollBar.getValue() +
e.getUnitsToScroll() *
verticalScrollBar.getUnitIncrement()
);
}
}
});
horizontalScrollBar.addMouseWheelListener(new MouseWheelListener() {
public void mouseWheelMoved(MouseWheelEvent e) {
if (e.getScrollAmount() == 0) return;
if (e.isControlDown() || e.isAltDown()) return; //BR//
if (e.getScrollType() == MouseWheelEvent.WHEEL_UNIT_SCROLL) {
horizontalScrollBar.setValue(
horizontalScrollBar.getValue() +
e.getUnitsToScroll() *
horizontalScrollBar.getUnitIncrement()
);
}
}
});
Hey all, I’ve been working on a module, almost finished, but I have been using v3.3.0 betas while doing so. I’ve belatedly decided I want users who are on v3.2 to be able to open my module, is even that possible now?
If I change the VassalVersion in the buildFile to 3.2.17, will that allow my module to be opened with that version of vassal? Thanks!
Hey all, I’ve been working on a module, almost finished, but I have been
using v3.3.0 betas while doing so. I’ve belatedly decided I want users
who are on v3.2 to be able to open my module, is even that possible now?
If I change the VassalVersion in the buildFile to 3.2.17, will that
allow my module to be opened with that version of vassal? Thanks!
Yes, in this particular case, that should work, because there aren’t
any component or file format changes in 3.3.0. (You should also update
the VassalVersion element in the moduleData file.)
It’s not something you should rely on working in general, however. (There
are modules for which this would not have worked between 3.1 and 3.2,
for example.)
This moves the Java bundled with the Windows and Mac builds from Java
13 (which is now EOL) to Java 14.
I already see an svn0383. Is that the current test target?
Yes.
9381 has some code cleanup, 9382 (probably) fixes a problem with playing
WAV files on some systems (Bug 12731), 9383 has a font rendering
improvement (Bug 12732).
All three of those contain the Java 14 change from 9380.