Posted by
ctrueden on
Mar 10, 2009; 5:14pm
URL: http://imagej.273.s1.nabble.com/Some-thoughts-about-ImageJ-tp3693353p3693358.html
Hi everyone,
Firstly I would like to respond to Herbie Glünder's comments about
maintaining compatibility versus elegant software design.
Herbie Glünder wrote:
> ImageJ is used by thousands of scientists as a valuable tool (and it was
> conceptualized as such) and there exist enormous amounts of macros and
> plug-ins that are used regularly over long periods of times without the need
> of adaptation. Most of us use ImageJ as a tool and besides many other
> features we love the ease of rapid prototyping by using the macro language.
>
I absolutely agree, for multiple reasons. From a purely pragmatic
standpoint, to be successful, a redesigned ImageJ would almost certainly
need to maintain compatibility with the vast body of existing work.
From a programmers point of view things may look different, but this is an
> old story going back to the early days of computers when there were people
> who wanted to use computers to solve problems and those who wanted to refine
> programming...
>
The dichotomy is not absolute. In many cases, with care it is possible to
have both. Moreover, I argue that to maximize ImageJ's effectiveness at
"solving problems," we must worry about "refining programming." Many of
those involved in this thread are not merely OCD design-obsessed programmers
-- our drive to retool the codebase specifically stems from encountering its
limitations in solving our problems. A complete refactoring, done
thoughtfully, would greatly benefit not just programmers, but users as well.
Johannes Schindelin wrote:
> The real issue is, after all: due to historical reasons, ImageJ uses
> neither Java5 niceties, nor does it have a completely orthogonal API
> (meaning that GUI, data structures and algorithms are not separated from
> each other).
>
I agree that adapting ImageJ into an MVC design would solve a lot of
problems, allowing it to be far more flexible as a toolkit beyond just the
ImageJ core application.
The question is: how can we keep the convenience for existing users, as
> well as get the changes in that are needed to move ImageJ forward from the
> technical side?
>
First idea that comes to mind:
A) Redesign the architecture from the ground up, according to MVC and other
best practices. Create a new tree of packages rooted at "ij2" to house it.
B) Begin migrating code from the old ij package into the new ij2 package.
The ij package API would remain identical, but the "guts" would be shifting
into ij2 over time. The code driving the stable ij API would become simpler
as more and more of it becomes delegation to logic in ij2. This process
gives us the flexibility to develop ImageJ v2.x independently of ImageJ
v1.x.
C) Plugins and macros needing new functionality can be coded against the ij2
API, while old plugins that use ij will continue to work. Over time we can
add deprecation warnings to everything in ij.*, to encourage developers to
migrate to ij2 when possible.
Of course, there are many challenges with this approach, but it seems like a
good way to get the best of both worlds.
Grant, it sounds like you have done some substantial work toward step A
above. How far did you get? Who else is interested in retooling the API?
-Curtis
On Tue, Mar 10, 2009 at 9:35 AM, Johannes Schindelin <
[hidden email]> wrote:
> Hi,
>
> On Tue, 10 Mar 2009, Joachim Wesner wrote:
>
> > One thing that should/could be adressed when "refactoring" ImageJ
> > would/could/SHOULD be the way the FFT or FHT routines are integrated
> > into the "kernel".
>
> This is getting too detailed for me. We are losing focus.
>
> The real issue is, after all: due to historical reasons, ImageJ uses
> neither Java5 niceties, nor does it have a completely orthogonal API
> (meaning that GUI, data structures and algorithms are not separated from
> each other).
>
> The question is: how can we keep the convenience for existing users, as
> well as get the changes in that are needed to move ImageJ forward from the
> technical side?
>
> Oh, and FWIW I think it would be wrong to move the discussion away from
> the ImageJ list, unless you absolutely want to lose contact with the
> users...
>
> Ciao,
> Dscho
>