When I'm feeling more up to it, I'll potentially rejigger this to
allow its use if it's available, but for now just simplify it so
folks can set a single icon.
Getdown is currently failing to create patch files because JarDiff is closing the outputstream. The attached patch comments it out, which seems to work.
moderately more sane progress indication.
It's still non-ideal, because, for example, we'll start out assuming everything
is length 1. So we'd have a queue like (1, 1, 1, 1). Then we start downloading
the first resource and see that we actually have (1500000, 1, 1, 1), so we
climb up to 99% downloading that first resource, and then we find out that we
have (1500000, 450000, 1, 1) and we pop back down to 70% or so, and so on as we
discover in turn that the web server lied to us about each file.
The alternative is to just sit at 25% for ages, then sit at 50% for ages, then
75%, etc. Maybe that's better... I guess I just like to see some sort of smooth
upward progress.
This is only a problem for me since I'm hosting a Getdown client on Github
which lies about Content-size in a HEAD request. So OOO projects will continue
to give accurate progress reports.
individually. Cap the actual download size at the reported size to ensure that
we don't end up borking our progress calculations if a web server returns a
"clever" value for content-size like 1 or 0, but then sends back real data.
Also sanitize the returned content-size in case the web server says something
awesome like -42. No one can be trusted on the Interwebs, least of all web
servers.
annoying dependency on javaws.jar (which no longer even includes JarDiff, now
that lives in $JAVA_HOME/samples/jnlp/servlet/jardiff.jar). We had already
forked JarDiffPatcher, so this completes the circle. Now I can also directly
fix some of the annoying JarDiff bugs we were working around, which I'll do at
some point.
os.name. If no architecture is specified, all architectures match, which
preserves the existing behavior.
Restructured things along the way to be more amenable to unit testing, and
added some unit tests.
much smaller than the background image. If we're going to change the
preferred size of the StatusPanel, we have to invalidate it so that
Window.pack knows to recompute the bounds. The reason this worked sometimes
(or even most of the time) is that there's a race condition between the
Getdown thread and the AWT thread: sometimes the real interface bits (_ifc)
are in place by the time initInterface is first called, sometimes not. For
the sake of consistency, we should probably fix that, but for now it's not
a big deal: the backgroundless interface is rarely visible.
Dave Hoover