[ImageJ-devel] Generalizing App. Framework

[Curtis Rueden]

Hi Grant,


> Your work on the application framework generalization looks great.
>

Thanks, I appreciate the code review.



I'll try to find some time to building an app. to try it out.


Sure, go for it. Just note that it is still not intended as a totally
general application framework. For example, the "ImageJ.createContext"
static methods always return an instance of the ImageJ class, not a
subclass. This is one of the (numerous) difficulties I alluded to when I
said I couldn't split out an "Application" interface in a more general way.

What is very convenient is to customize your ImageJ with many unique
services. So in that sense, you can create your own application. And now
those services can even change the application title by calling
ImageJ#setTitle(String).

So really, you can build anything you want with this framework (including
apps that have absolutely nothing to do with image processing), as long as
you are willing to accept that the application context is called "ImageJ"
no matter what. It just seemed too confusing to newbies to call it an
"AppContext" or something like that, even though that's really what it is.


> An additional ImageJ-specific reference that could be generalized:
> In imagej.util.AppUtils#**getBaseDirectory() there are references to
> imagej


Yep. It's a convenience method. The other getBaseDirectory signatures are
more general-purpose, allowing you to find the base directory relative to
any class. Still, there are a number of assumptions (i.e., heuristics) in
those methods. I just pushed a commit that describes it in excruciating
detail. See:

https://github.com/imagej/imagej/blob/6fe64ddf/core/core/src/main/java/imagej/util/AppUtils.java#L114

It's convenient to use your IDE's rendering of the Javadoc, since the
javadoc uses lots of HTML. Also, after tonight's nightly build, the new
javadoc will be online at:

http://jenkins.imagej.net/job/ImageJ-daily/javadoc/imagej/util/AppUtils.html#getBaseDirectory(java.lang.String,
java.lang.String)

In short, though we welcome any specific suggestions for improvement, we
believe the current code is sufficiently general for any application.

Let me know if you have any questions about it!


> (BTW, just wondering, why are MenuEntry & MenuPath in the imagej rather
> than imagej.menu package?)


That one is tricky. I'm torn on moving those to imagej.menu. They would be
more intuitive there. The rationale is that we have tried to avoid having
base packages with dependencies on their subpackages, because it creates
circular package dependencies (usually, subpackages depend on classes
higher up the tree). Of course, the compiler doesn't complain about it, but
these circular dependencies often indicate sloppy package design. In this
case, MenuEntry and MenuPath are used by UIDetails, which is a very
general-purpose interface. I don't necessarily like that it is in the
imagej base package, but after eliminating imagej.ext I was not sure where
else would make sense for it. Ideas, anyone?

Regards,
Curtis


On Fri, Aug 31, 2012 at 9:24 AM, Grant B. Harris <gharris at mbl.edu> wrote:

> Curtis --
>
> Your work on the application framework generalization looks great.
> I'll try to find some time to building an app. to try it out.
>
> An additional ImageJ-specific reference that could be generalized:
> In imagej.util.AppUtils#**getBaseDirectory() there are references to
> imagej
>
>     public static File getBaseDirectory() {
>         final String property = System.getProperty("ij.dir");
>         ...
>         final String appPath = getBaseDirectory("imagej.Main"**);
>         ...
>     }
>
> Wondering if there is a way to generalize those...
>
> (BTW, just wondering, why are MenuEntry & MenuPath in the imagej rather
> than imagej.menu package?)
>
> - Grant
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20120831/2d7569d6/attachment.html>