I have to admit that at first, I also assumed that the progress should behave in the way you described. But it actually has worked for a long time as described here:

http://imagej.nih.gov/ij/developer/api/ij/IJ.html#showProgress(int,%20int)

In short: "Updates the progress bar, where the length of the bar is set to (currentValue+1)/finalValue of the maximum bar length."

I agree that it is unintuitive, but unfortunately, it cannot be changed, for backwards-compatibility. (Instead I have to fix all my plugins...)

Sorry!

(In reply to comment #1)
> I agree that it is unintuitive, but unfortunately, it cannot be changed, for
> backwards-compatibility.

This is major counter intuitive. Not fixing (not blaming you, but the upstream ImageJ devs) what is clearly a bug just because old users are expecting the problem and wrote workarounds rather than bug fixes doesn't make any sense. I guess this proves that a documented bug is a feature.

Backwards compatibility is all very nice but I do hope that the ImageJ2 devs aren't too afraid to break weird things like this. Even though they said they were trying the best to not break anything on the last conference.

Well, thank you anyway for the quick reply. It's very appreciated.

(In reply to comment #2)
> Backwards compatibility is all very nice but I do hope that the ImageJ2 devs
> aren't too afraid to break weird things like this. Even though they said they
> were trying the best to not break anything on the last conference.

ImageJ2 will definitely address unintuitive issues like this. Regarding backwards compatibility, the goal is not for the new library or UI to behave the same as before (although all other things being equal, it will in many cases), but rather for old code such as macros and plugins to still function the same way.

This is possible because ImageJ2 is bundled with the latest v1.x version of ij.jar, so macro and plugin execution is faithful. The difference is that the new ImageJ2 interface then translates "legacy" objects such as ij.ImagePlus into the new equivalent objects such as imagej.Dataset.

Currently, the IJ2 user interface exposes many IJ1 plugins directly in the menus, but we have begun to port them over to IJ2. Over time all IJ1 commands will disappear from the menus. But they will still be available, under the hood, for legacy code to access. Hopefully, though, the advantages of porting code to the IJ2 platform will be compelling enough that IJ1 code will fade away over the new few years.

I do hope sincerely, though, that backwards compatibility within the IJ2 context will be maintained as well as (or better than) in IJ1.

I agree that some things are counterintuitive -- I myself was very surprised about finding out that the behavior reported here was actually intended -- but breaking existing setups is always more painful than to accomodate the expectations of intelligent and flexible developers.