Hi Grant,<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>Your work on the application framework generalization looks great.<br>
</blockquote><div><br></div><div>Thanks, I appreciate the code review.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I'll try to find some time to building an app. to try it out.</blockquote>
<div><br></div><div>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.</div>
<div><br></div><div>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).</div>
<div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>An additional ImageJ-specific reference that could be generalized:<br>
In imagej.util.AppUtils#<u></u>getBaseDirectory() there are references to imagej</blockquote><div><br></div><div>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:</div>
<div><br></div><div><a href="https://github.com/imagej/imagej/blob/6fe64ddf/core/core/src/main/java/imagej/util/AppUtils.java#L114">https://github.com/imagej/imagej/blob/6fe64ddf/core/core/src/main/java/imagej/util/AppUtils.java#L114</a></div>
<div><br></div><div>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:</div><div><br></div>
<div><a href="http://jenkins.imagej.net/job/ImageJ-daily/javadoc/imagej/util/AppUtils.html#getBaseDirectory(java.lang.String">http://jenkins.imagej.net/job/ImageJ-daily/javadoc/imagej/util/AppUtils.html#getBaseDirectory(java.lang.String</a>, java.lang.String)</div>
<div><br></div><div>In short, though we welcome any specific suggestions for improvement, we believe the current code is sufficiently general for any application.</div><div><br></div><div>Let me know if you have any questions about it!</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>(BTW, just wondering, why are MenuEntry & MenuPath in the imagej rather than imagej.menu package?)</blockquote>
<div><br></div><div>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?</div>
<div><br></div><div>Regards,</div><div>Curtis</div><div><br></div><div><br><div class="gmail_quote">On Fri, Aug 31, 2012 at 9:24 AM, Grant B. Harris <span dir="ltr"><<a href="mailto:gharris@mbl.edu" target="_blank">gharris@mbl.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Curtis --<br>
<br>
Your work on the application framework generalization looks great.<br>
I'll try to find some time to building an app. to try it out.<br>
<br>
An additional ImageJ-specific reference that could be generalized:<br>
In imagej.util.AppUtils#<u></u>getBaseDirectory() there are references to imagej<br>
<br>
public static File getBaseDirectory() {<br>
final String property = System.getProperty("ij.dir");<br>
...<br>
final String appPath = getBaseDirectory("imagej.Main"<u></u>);<br>
...<br>
}<br>
<br>
Wondering if there is a way to generalize those...<br>
<br>
(BTW, just wondering, why are MenuEntry & MenuPath in the imagej rather than imagej.menu package?)<span class="HOEnZb"><font color="#888888"><br>
<br>
- Grant<br>
</font></span></blockquote></div><br></div>