This little chunk of code has been tweaked and cargo'd forward for years
with no documentation as to what's going on.
What I object to is the blatent disregarding of the width specified in
getdown.txt with something calculated internally. (width - x*2)
GIGO; fix your fucking getdown.txt.
- If we are not granted privileges, reading the metadata breaks, which
is why the fallback was first added.
- Later it was tweaked because getWidth() can sometimes report 0 and
that would cause the fallback width to be negative.
- Allow multiple percentages to be specified for a step. The lowest one that's
higher than the current percentage is used.
- It seems sometimes the UI is shown after some progress is made. Track
the percentage we're at when the UI is shown and reset that to be the new
0, scaling subsequent progress to fill the remainder.
I added this convinced I needed it, but now I'm seeing that it's always
at 0 when the UI is shown...
Perhaps I'll revisit that after I do some other stuff...
Ellipses on buttons/menu items typically means "pressing this
will not invoke an action directly because more information/customization
is needed". For example the ubiquitous "Print..." displays a
printing dialog, it doesn't actually start printing.
after the status, incrementing every second.
Even if the status or percentage doesn't update for a while, the user
will know that the updater is still "working".
This could cause problems but I believe that any time we display the
time remaining we are also showing a short status string.
Hand-massaged the translations, hopefully everything still makes sense
in each language.
but it wasn't doing the right thing. Fixed it.
I honestly have no idea how this was working. Maybe it just wasn't.
Maybe we never noticed before because with the per-step progress
bars we weren't seeing it exceed 100 percent.
And then use that instead of the UnifiedProgressObserver I wrote,
before I saw MetaProgressObserver.
Part 1: the unification.
Two things actually:
- If there are auxiliary groups, the resources from all groups were
downloaded all together, but patched individually. So each patcher
would restart the progress bar from 0-100%. Created a unified
progress observer that merely gives each patching phase an even
division of the percentage.
- I enumerated the major steps involved in getting down, and assigned
a completely arbitrary max progress percentage to each.
All percent progress reports are now bounded to the range of
the max for the current step and previous step's max reported
progress. Backwards progress is ignored, so if getdown goes
back and re-does some steps the bar may "stall".
If a step is skipped, the progress bar doesn't jump ahead, rather
it will use the range of any skipped steps to more fully
report the 0-100% progress of the current step.
I'm going to try this out and make adjustments.
This feature isn't done, part 2 is moving any time estimate
up to the "status" label (instead of the "progress" label).
Getdown first tries with the optimum arguments included. If the
process starts successfully, it continues as normal; otherwise, it
tries again without the optimum arguments. The arguments in
"extra.txt" are included after the optimum arguments, so that they can
override them (for instance, if you have both -mx256m and -mx1g on the
command line, the JVM will use whichever comes last).
calling out to Ant to do the Proguard build.
Running Ant from within Maven (which then runs Maven from within Ant) no longer
works as of Maven 3.
While I was in here, I changed the build to use the Proguard-ed artifact as the
primary artifact, and changed the POM to reflect that none of the dependencies
are transitive.
page hosting the applet and the launched application through a simple server
socket bound to the loopback address on any available port (where the port
is passed to the application as a system property). Not tested yet, but it
shouldn't affect any deployments that don't specifically enable it.
of using the signers on the jar file. Also tidied up the code that passes
certificates around so that we get rid of that wonderful Object[] as early as
possible.
getdown-pro.jar and it's only 10% larger (109k -> 121k), and it vastly
simplifies life for users.
Just use getdown-pro.jar for all of your Getdown-related needs:
- use it to install your application
- use it in your build scripts for the various Getdown tasks
- link against it in your app to use LaunchUtil or to embed Getdown
We'll even ship this on the website as simply getdown.jar. I'm tempted to ship
this in Maven and modify the main Getdown POM to not export any of its
dependencies. However, that will require a bunch of build file tweaking, which
I'd rather save for another day.
of inconsistent-with-one-another-and-with-getdown.txt-and-limitation-ridden
'properties' and 'app_properties' mechanisms from ancient history.
Unfortunately, Sun in their infinite wisdom decided that being able to
enumerate applet parameters was "not doing it right" and provided no mechanism
for doing so. So we have to use annoying increasing int suffixes.
Use like so:
<object ..>
<param name="jvmarg0" value="-Xmx256M"/>
<param name="jvmarg1" value="-Danswer=42"/>
<param name="jvmarg2" value="-Dtrix=for kids"/>
<param name="jvmarg3" value="-Dfoodir=%APPDIR%"/>
<param name="apparg0" value="--username"/>
<param name="apparg1" value="elvis"/>
</object>
Ray Greenwell