You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
By bundling ImageJ1 with the ImageJ2 distribution, we can support the IJ1 macro language as is with full backward compatibility. This is great, but users will want more: they want to "mix and match" IJ2 API calls within existing macros. This feature will be an excellent way for people to begin migrating existing workflows into IJ2 without needing to switch all at once.
One way to provide such capabilities would be to port the IJ1 macro language functions on top of BeanShell. This approach would be very powerful because it would allow IJ2 macros to harness the full IJ1 and IJ2 Java APIs, in addition to all the existing macro functions. It would also provide object oriented capabilities, required anyway by IJ2.
The macro language is largely syntactically compatible with BeanShell, with four notable exceptions:
Passing uninitialized variables to built-in functions for side-effect assignments. E.g.: getSelectionCoordinates.
The function keyword for declaring subroutines.
Functions with no arguments not needing parentheses.
The (disabled by default) expandable array syntax.
We have already solved 1), and are confident that 2) and 3) will be very easy. 4) is more difficult but enabling it in IJ1 issues a warning about IJ2 compatibility so that users are aware of the consequences.
Alternately, we can simply delegate to ImageJ1's macro evaluator, though this approach would largely lose the ability to mix and match macro code with ImageJ2 API calls.
Either way, this feature will take the form of a new ScriptLanguage for ImageJ macros, bundled as part of imagej-legacy.
By bundling ImageJ1 with the ImageJ2 distribution, we can support the IJ1 macro language as is with full backward compatibility. This is great, but users will want more: they want to "mix and match" IJ2 API calls within existing macros. This feature will be an excellent way for people to begin migrating existing workflows into IJ2 without needing to switch all at once.
One way to provide such capabilities would be to port the IJ1 macro language functions on top of BeanShell. This approach would be very powerful because it would allow IJ2 macros to harness the full IJ1 and IJ2 Java APIs, in addition to all the existing macro functions. It would also provide object oriented capabilities, required anyway by IJ2.
The macro language is largely syntactically compatible with BeanShell, with four notable exceptions:
We have already solved 1), and are confident that 2) and 3) will be very easy. 4) is more difficult but enabling it in IJ1 issues a warning about IJ2 compatibility so that users are aware of the consequences.
Alternately, we can simply delegate to ImageJ1's macro evaluator, though this approach would largely lose the ability to mix and match macro code with ImageJ2 API calls.
Either way, this feature will take the form of a new
ScriptLanguage
for ImageJ macros, bundled as part ofimagej-legacy
.Migrated-From: http://trac.imagej.net/ticket/837
The text was updated successfully, but these errors were encountered: