Anywhere you can load a png, gif or jpg in 3.0, you can now load an svg image instead.
There has been some discussion of having GamePieceImages generate svg’s, but currently, there are no other plans beyond allowing them to be used in place of existing images.
There’s no threading problem with the methods which return an Icon, BTW,
as that’s a Swing component and so those methods should only ever be called
from the EDT anyhow. It’s just the ones which return something else from
the map.
Yes, except that they wouldn’t need to be methods calls at all—you’d just
have a private static member called instance, and call methods on that.
Well, it doesn’t need to be an inner private class, but there are some
benefits of having it be one. In particular, it’s nicer to have an inner
private class if the alternative is having a huge static block for
initialization—all of that stuff can be put into the ctor of the inner
private class, then. Also, having an inner private class future-proofs us
somewhat, as fewer changes need to be made if we decide someday that this
shouldn’t be a singleton anymore.
Right now, we don’t have plans to do more, but our present plans extend
into only about 3.3 or so. What you’re suggesting here had never occurred
to me, actually. It’s not a bad idea, but probaby won’t get any attention
in the next 6-9 months.
What’s the best way to report a bug if you are in a section of code and realise something has gone wrong, but no Exception has actually been raised. I’d like to raise a Bug dialog with an error message and a stack trace to where I am now in the code.
Not that it’s difficult to create this without needing the whole
exception catching machinery:
new Throwable().printStackTrace();
will print out the current stack trace. This can be wrapped up with a
StringOutputStream and a dialog in a fairly simple utility method if
needed, although it does add one additional method call to the stack:
public void showStack() {
StringWriter s = new StringWriter();
new Throwable().printStackTrace(s);
JOptionPane.showMessageDialog(null, s.toString());
}
Next task is to wrap my head around the threading issues. It is not something I have looked into in detail before.
New version in swampwallaby-work@4927 which I think resolves Concurrency and Error Handling issues.
The idea is that the IconFactory scan of the Vassal installation might take a little time, so I fire it off in a background thread to allow the module to continue initializing. However, it is possible a request to getIcon() might come in before the scan has completed and will need to wait for the preload thread to complete.
Once the preload thread is complete, concurrency on the iconFamilies map is no longer an issue. Concurrency is handled when individual icons are needed to be built in the IconFamily class.
This reminds me of an idea I had the other night. We should add a “Report a Bug” entry to the Help menu! Let people report bugs manually just like the automated bug reporter does, but without having to go to the SourceForge site. We’ll always upload the errorLog of course, so no more hassling people to remember to include the VASSAL version, Java version, OS, module name, etc.
That’s been on my list of things to do since I created the Bug Dialog. The
reason I haven’t done it yet is that the dialog text needs to be different,
as well as the path through the panes in the dialog.
I think it’s too late to do this for 3.1, since it would require going back
to the translators again.
Another thing worthwhile in the help menu (or somewhere) would be connected links in module library/module directly to main website and forums for users to find things not bug related perhaps
That’s been on my list of things to do since I created the Bug Dialog. The
reason I haven’t done it yet is that the dialog text needs to be different,
as well as the path through the panes in the dialog.
I think it’s too late to do this for 3.1, since it would require going back
to the translators again.
to be in the module currently being edited/played.
I think I have tracked down the source of the problem - SourceOpBitmapImpl.eval() calls
in = archive.getImageInputStream(name);
to get the archive to return a Stream to the image, DataArchive.getImageInputStream() does this:
if (fileName.startsWith(“/”)) {
final InputStream in = getClass().getResourceAsStream(fileName);
if (in != null) return in;
throw new FileNotFoundException("Resource not found: " + fileName);
}
Yes, I was going to tell you that the problem is with getImageInputStream().
I think the best solution is to stop using getImageInputStream() and just
use getInputStream() directly, now that we are pulling images from more
places than just images/.
Hmm, that appears to be a fairly major rewrite of several of the ImageOp implementations, plus whatever calls them to add ‘image/’ to the file name as required.
Plus, as far as I can see, getInputStream() makes no attempt to load a path commencing with “/” from VEngine .jar.
Another problem is that ArchiveWriter.addImage(path, name) ignores pathnames. It loads all SVG images into /images specifically.
It looks like you did not have pathnames in mind when writing the ImageOp stuff, it only works if everything goes into /images. I am very hesitant to go hacking around in there. Can I leave this with you? I’ll suspend my Icon work until you sort it out.
I don’t believe this is a problem in 3.1, it has only come up because I am trying to stick Icon files where they won’t fit
Nope. 2521925 is our first 3.2 bug (which, BTW, I’ve looked at and I don’t
understand how it could even happen).
I’ll take care of all of this. The root of the problem is that DataArchive
was built on the assumption that all of the images would be in images/,
which is no longer the case. Requesting a path rather than just an image
name would solve this problem.