Allow only one instance of the DefaultLegacyService

In a later commit, we might want to solve this issue a bit cleaner;
while we cannot hope to execute legacy commands and macros in multiple
legacy services within the same class loader, we may still synchronize
preferences to a certain degree.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
CodeHacker: avoid using the LogService

At the time CodeHacker is running, we cannot hope for a LogService
being initialized already.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
CodeHacker: pass LegacyService instance to patched functions

We really need the instance of the legacy service in those functions...

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
LegacyImageMap: offer the list of handled images

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
LegacyImageMap: we need a reference to the current legacy service

To support the upcoming legacy ImageJ 1.x mode, we will need to
determine in the legacy image map whether to hold off displaying
images based on said mode, so we need to have a reference to the
service which knows whether that mode is active.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add the method ApplicationFrame#setVisible(boolean)

LegacyService's toggleLegacyMode() will use this method.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
SwingImageWindow: avoid pack() when hiding the window

This is needed for the upcoming Help>Legacy Mode, which would otherwise
experience an 'IllegalStateException: Cannot sync viewport from thread'.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
CodeHacker: remove unused replaceMethod() method

For the legacy mode, we should avoid replacing methods in every case,
so we will not need this method anymore, ever.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
WIP: Introduce a legacy mode to the LegacyService

To fall back to original ImageJ1 (e.g. should some plugin or macro not
work in ImageJ2 as it did in ImageJ1), we'd like to be able to drive a
patched ImageJ1 in such a way that it behaves exactly like unpatched
ImageJ1 (except still synchronizing all the data with ImageJ2).

This change introduces a flag in the class LegacyService, and changes the
Javassist patches so that the legacy mode is heeded.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
WIP: Add Help>Start Legacy ImageJ 1.x Mode

Since it is very hard (or might be impossible) to achieve full 100%
backwards-compatibility with ImageJ1, we want to have one last way out for
users whose plugin/macro might not work in ImageJ2, namely to show the old
ImageJ1 GUI and lose all the ImageJ2 goodness.

This is what Help>Start Legacy ImageJ 1.x Mode does.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
WIP: Implement legacy mode's Help>Stop Legacy ImageJ 1.x Mode

When the tasks are finished in the legacy mode, we want to go back...

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
WIP: make 'Ctrl+L Stop Legacy Mode' work in legacy mode

The big problem here is that we'd like to avoid introducing the
dependency on Swing, but ATM part of the code needs to be executed
on the EDT.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
HACK: WIP: Avoid showing IJ2 windows in legacy mode

We need to make this more robust before merging to 'master'.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
WIP: Verify that two ImageJ contexts can have two different LegacyServices

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>