Ecoinformatics Redmine: Issueshttps://projects.ecoinformatics.org/ecoinfo/https://projects.ecoinformatics.org/ecoinfo/ecoinfo/favicon.ico?14691340362015-08-12T23:39:08ZEcoinformatics Redmine
Redmine Kepler - Bug #6829 (Closed): ant change-to fails under Windows Server 2012 R2 with Cygwinhttps://projects.ecoinformatics.org/ecoinfo/issues/68292015-08-12T23:39:08ZChristopher Brookscxh@eecs.berkeley.edu
<p>Under Windows Server 2012 R2 with Cygwin, I ran<br /><pre>
mkdir kepler.modules
cd kepler.modules
svn co https://code.kepler-project.org/code/kepler/trunk/modules/build-area
cd build-area
</pre></p>
<p>and then ant change-to failed:</p>
<pre>
$ ant change-to -Dsuite=kepler
Buildfile: C:\Users\cxh\src\kepler.modules\build-area\build.xml
change-to:
[change-to] Copying 1 file to C:\Users\cxh\src\kepler.modules\build-area
[change-to] Retrieving modules....
[change-to]
[change-to] kepler:
[change-to] Downloading (if necessary) kepler...
[change-to] svn co -r head https://code.kepler-project.org/code/kepler/trunk/modules/kepler C:\Users\cxh\src\kep\
ler.modules\kepler
[change-to] svn: E000002: Can't make directory '/cygdrive/c/Users/cxh/src/kepler.modules/build-area/C:\Users\cxh\
\src\kepler.modules\kepler': No such file or directory
[change-to]
BUILD FAILED
C:\Users\cxh\src\kepler.modules\build-area\build.xml:104: ERROR: It appears that the command did not execute pro\
perly and exited with an exit code of: 1
Total time: 1 second
cxh@AMPERE ~/src/kepler.modules/build-area
$
</pre>
<p>I can give out accounts on ampere.eecs.berkele.edu if necessary.</p> Kepler - Bug #6167 (New): Model Context Menu should have the enableBackwardTypeInference choicehttps://projects.ecoinformatics.org/ecoinfo/issues/61672013-10-23T01:07:20ZChristopher Brookscxh@eecs.berkeley.edu
<p>Ptolemy II now supports backward type inference. The way this is enabled is that the top level container has a parameter called "enableBackwardTypeInference" that is set to true or false.</p>
<p>In Ptolemy II's Vergil, this is visible by right clicking on the background of the top level model.</p>
<p>This functionality is not present in the devel tree of Kepler.</p>
<p>The workaround is to drag in a Parameter, name it "enableBackgroundTypeInference" and set the value to true.</p> Kepler - Bug #6165 (Resolved): The names of instances of the Stop actor do not display in Mac OSX.https://projects.ecoinformatics.org/ecoinfo/issues/61652013-10-22T00:48:43ZChristopher Brookscxh@eecs.berkeley.edu
<p>On Kepler-users, Kenneth Jones wrote:</p>
<blockquote>
<p>The names of instances of the Stop actor do not display in Mac OSX. Let me know if you need more info.</p>
</blockquote>
<p>Indeed, dragging in the Stop Actor results in icons without instance names</p> Kepler - Bug #5633 (Resolved): Actor/Attribute Search/Find Facility needs menu choiceshttps://projects.ecoinformatics.org/ecoinfo/issues/56332012-06-22T21:40:21ZChristopher Brookscxh@eecs.berkeley.edu
<p>Edward developed a search facility for models.<br />Under Mac OS X in the Kepler trunk, if the mouse is over the graph canvas,<br />then typing Command-F brings up a search dialog.</p>
<p>This dialog should be added to the Kepler menus.</p> Kepler - Bug #5020 (Resolved): 2.0-RC3 installer: R Kepler Module is not optionalhttps://projects.ecoinformatics.org/ecoinfo/issues/50202010-05-20T17:28:08ZChristopher Brookscxh@eecs.berkeley.edu
<p>When installing Kepler-2.0-RC3, I'm presented with<br />two choices:<br />Kepler<br />R Kepler Module</p>
<p>Both are required, I can't uncheck "R Kepler Module",<br />so why bother with this window?</p> Kepler - Bug #3903 (New): Use Java logging utilities instead of Apache commons logging facilityhttps://projects.ecoinformatics.org/ecoinfo/issues/39032009-03-18T19:21:30ZChristopher Brookscxh@eecs.berkeley.edu
<p>ersonally, I'd like to switch to the logging utilities that<br />now ship with Java, see<br /><a class="external" href="http://java.sun.com/j2se/1.4.2/docs/guide/util/logging/">http://java.sun.com/j2se/1.4.2/docs/guide/util/logging/</a><br />The advantage is that it would be one less jar file to ship.<br />A quick search finds 144 files that use the apache logging facility.<br />Most of these changes could be handled automatically by a script.</p>
<p>Notes about the logging system can be found at<br /><a class="external" href="https://kepler-project.org/developers/reference/using-commons-logging">https://kepler-project.org/developers/reference/using-commons-logging</a></p> Kepler - Bug #3105 (Resolved): Getting Started link on Welcome Page should lead to demoshttps://projects.ecoinformatics.org/ecoinfo/issues/31052008-01-29T00:19:50ZChristopher Brookscxh@eecs.berkeley.edu
<p>This might be old news, but I'll report it anyway.</p>
<p>When I start up Kepler, the "Welcome" window has a link "Getting Started",<br />which leads to kepler/configs/kepler/introScientists-beta1.htm</p>
<p>introScientists-beta1.htm should have a link to <br />kepler/src/configs/ptolemy/configs/kepler/introScientists.htm<br />or else perhaps the Welcome Window should link directly to introScientists.htm<br />It is important that the demos be easily visble to new users.</p> Kepler - Bug #3103 (Resolved): Building actor documentation from within Kepler failshttps://projects.ecoinformatics.org/ecoinfo/issues/31032008-01-25T00:49:48ZChristopher Brookscxh@eecs.berkeley.edu
<p>If the actor documentation does not exist, then when I select<br />Documentation -> Display, a window comes up that allows me to build<br />the documentation. The build continues along for awhile and then fails with.<br />BUILD FAILED<br />c:\cxh\src\kepler\build.xml:1232: The following error occurred while executing this line:<br />c:\cxh\src\kepler\build.xml:1280: The following error occurred while executing this line:<br />c:\cxh\src\kepler\build.xml:1289: Javadoc failed: java.io.IOException: CreateProcess: "c:\program files\java\jdk1.5.0_11\bin\javadoc.exe" -d c:\cxh\src\kepler-docs\dev\documentationFramework\generatedJavadocs -J-DKEPLER=c:\cxh\src\kepler -classpath c:\cxh\ptII -sourcepath c:\cxh\ptII -doclet doc.doclets.PtDoclet -docletpath c:\cxh\ptII\lib\kepler.jar;c:\cxh\src\kepler;c:\cxh\src\kepler\configs;c:\cxh\src\kepler\lib;c:\cxh\src\kepler\lib\images;c:\cxh\src\kepler\build\kepler-configs.jar;c:\cxh\src\kepler\build\kepler-icons.jar;c:\cxh\ptII\lib\diva.jar;c:\cxh\ptII\lib\jython.jar;c:\cxh\ptII\build\ptolemy-doc.jar;c:\cxh\ptII\build\classes;c:\cxh\ptII\build\src;c:\cxh\ptII\ptolemy\distributed\jini\jar\tools.jar;c:\cxh\ptII\ptolemy\distributed\jini\jar\jini-core.jar;c:\cxh\ptII\ptolemy\distributed\jini\jar\sun-util.jar;c:\cxh\ptII\ptolemy\distributed\jini\jar\reggie.jar;c:\cxh\ptII\ptolemy\distributed\jini\jar\jsk-policy.jar;c:\cxh\ptII\ptolemy\distributed\jini\jar\jsk-platform.jar;c:\cxh\ptII\ptolemy\distributed\jini\jar\start.jar;c:\cxh\ptII\ptolemy\distributed\jini\jar\reggie-dl.jâ€</p> Kepler - Bug #2420 (Resolved): Need a 25x25 kepler icon to decorate title barshttps://projects.ecoinformatics.org/ecoinfo/issues/24202006-04-18T02:58:30ZChristopher Brookscxh@eecs.berkeley.edu
<p>Hi Laura,<br />I'm assigning this bug to you because you will either know how to fix it<br />or know who to assign this one to. In<br /><a class="external" href="http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2343">http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2343</a> <br />you pointed out that we need a 25x25 Kepler<br />icon. I hacked one up at<br />configs/ptolemy/configs/kepler/KeplerSmallIcon.gif<br />but it is ugly.</p>
<p>BTW - The configuration sets _applicationIcon the a FileParameter.<br />TableauFrame reads the _applicatonIcon parameter of<br />the configuration.</p>
<p>_Christopher</p> Kepler - Bug #2414 (New): Opening a preexisting model should open in a blank viewerhttps://projects.ecoinformatics.org/ecoinfo/issues/24142006-04-13T21:42:32ZChristopher Brookscxh@eecs.berkeley.edu
<p>In "add welcome screen for release 1.0" at<br /><a class="external" href="http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2343">http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2343</a></p>
<p>Matthew wrote:</p>
<blockquote>
<p>Now this has been added, here is a very common use case, which seems incorrect<br />(reported by Kevin):</p>
<p>1) User starts kepler - gets blank graph frame, with new welcome screen in front</p>
<p>2) User dismisses welcome screen, and is left with blank graph frame</p>
<p>3) User then does "File->Open" and opens an existing workflow</p>
<p>4) The workflow then opens in a <strong>new</strong> graph frame, leaving the original, empty <br />graph frame on the screen.</p>
<p>Proposed resolution:</p>
<p>BEST: at startup, if user does the above, then the workflow gets opened in the<br /><strong>existing</strong> blank graph frame. Subsequently-opened workflows open up in <strong>new</strong><br />graph frames, as before</p>
</blockquote>
<blockquote>
<p>INTERIM: if we don't have time to implement the above for this release, then<br />check to see if we are in the above use-case, and if so, close the blank graph<br />frame after the first workflow has been opened</p>
<p>Any other thoughts/comments/ideas?</p>
</blockquote>
<p>I wrote:</p>
<blockquote>
<p>Probably File Open should be smart enough to realize that the current window<br />is mostly blank and a candidate for replacement. I'm not sure if<br />this will be very easy. For example, when one does File -> Save As, and<br />uses a new name, a new window appears. We need to handle "Unnamed" models<br />specially. I can take a look at this at some point, but probably not before<br />early March.</p>
</blockquote>
<p>I won't have time before Kepler 1.0, so I'm opening this as a separate <br />enhancement. This new bug has to do with the blank or Unnamed models,<br /><a class="external" href="http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2343">http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2343</a><br />has to do with the welcome window.</p> Kepler - Bug #2352 (Resolved): Preferences System needs to be resolvedhttps://projects.ecoinformatics.org/ecoinfo/issues/23522006-02-09T17:51:59ZChristopher Brookscxh@eecs.berkeley.edu
<p>I'm creating a bug for this because<br /><a class="external" href="http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2343">http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2343</a><br />"add welcome screen for release 1.0" depends on it.<br />I wrote:</p>
<p>Hi Edward,<br />I'm hacking up the Welcome window and would like to have a way<br />the window so it has a "Please don't show me this dialog again" <br />checkbox and I have some questions about VergilPreferences.</p>
<p>- vergil.VergilPreferences should probably be renamed to<br />PtolemyPreferences and moved to ptolemy.actor.gui so that the<br />actor.gui.WelcomeWindow class can get at it and ptolemy.actor.gui does<br />not depend on vergil.</p>
<p>In fact, getting a preference is a fairly basic task, so this<br />should go in some non-gui base class. If we use plain old java<br />properties, then perhaps we could have a preferences class in<br />ptolemy.util? I'd like to be able to get at preferences without<br />requiring moml.<br />Another preference I'd like to see is a way for the user to adjust<br />how much detail the GraphicalMessageHandler window initially shows.<br />GraphicalMessageHandler is in ptolemy.gui and only imports<br />ptolemy.util, so MoML is not available.</p>
<p>- We need a way to access a global property when we don't have a<br />container. In general, I think the Kepler developers are confused<br />about how we should get a Configuration from anywhere in the code.<br />So, we need a preferenceValue(String preferenceValue) that<br />does not require a context or container and gets the value of<br />the global preference.</p>
<p>Comments?</p>
<p>I've included some email below that has further details</p>
<p>_Christopher</p>
<blockquote>
<p>To: Matthew Brooke <<a class="email" href="mailto:brooke@nceas.ucsb.edu">brooke@nceas.ucsb.edu</a>><br />cc: <a class="email" href="mailto:eal@eecs.berkeley.edu">eal@eecs.berkeley.edu</a><br />From: "Christopher Brooks" <<a class="email" href="mailto:cxh@eecs.berkeley.edu">cxh@eecs.berkeley.edu</a>><br />Subject: Re: [Bug 2343] - add welcome screen for release 1.0<br />In-reply-to: Your message of Fri, 20 Jan 2006 16:28:29 -0800.<br /><<a class="email" href="mailto:43D1802D.3000607@nceas.ucsb.edu">43D1802D.3000607@nceas.ucsb.edu</a>><br />Date: Sat, 21 Jan 2006 18:07:54 -0800<br />Sender: <a class="email" href="mailto:cxh@carson.EECS.Berkeley.EDU">cxh@carson.EECS.Berkeley.EDU</a></p>
<p>I've taken the liberty of ccing Edward here.</p>
<p>Matthew Brook writes:</p>
<blockquote>
<p>Christopher:</p>
<blockquote>
<p>Perhaps Edward's preferences manager<br />(ptolemy.vergil.VergilPreferences) can be used?</p>
</blockquote>
<p>When i started the SVG icon stuff, I needed to access properties files<br />from various parts of the code, and spent a lot of time trying to use<br />ptII's existing configuration.xml, to no avail. I finally figured it<br />just wasn't 'available' for enough of the codebase at runtime, without<br />hard-coding paths in order to re-load it (or maybe I'm just too<br />dumb...).</p>
</blockquote>
<p>Right this is a problem in general. It is not always easy to get<br />at the configuration, you usually need a model that was read in.</p>
<blockquote>
<p>So - I went ahead and used java's built-in<br />resourcebundle/properties classes for storing prefs. This is<br />overkill/inappropriate in some places (for example, many of the settings<br />are not localizable, so do not really need resourcebundle files), but it<br />works marvelously. I guess in the meantime, Edward created the<br />VergilPreferences thing, which I haven't looked at - so now we have a<br />proliferation on our hands... :-(</p>
<p>Anyway - I have put all the ui-related settings in <strong>.properties files in<br />configs/ptolemy/configs/kepler/, and they all have names like:<br />ui</strong>***.properties. The 'main' one is uiSettings.properties.</p>
<p>Up to now, these only contain application settings (ie read-only) rather<br />than user settings - so we still need to create a user-settings file for<br />these read/write props. Is that what VergilPreferences currently does?<br />if it's ultra-simple to use, and easy to get a reference to the props<br />class (say via a static method somewhere) let's use it! If not, then<br />let's use POJ!</p>
<p>m</p>
</blockquote>
<p>Right, VergilPreferences saves its perferences in<br />~/.ptolemyII/VergilPreferences.xml<br />or c:/Documents and Settings/username/ptolemyII/VergilPreferences.xml</p>
<p>I think it is fine to have the ui read only settings in<br />configs/ptolemy/configs/kepler</p>
The primary entry point in VergilPreferences is:<br />/** Check to see whether a preference of the specified name is
<ul>
<li> defined in the specified context, and if it is, return it's value.</li>
<li> Note that if there is an error in the expression for the preference,</li>
<li> then this method will return null and report the error to standard ou\</li>
</ul>
</blockquote>
<p>t.</p>
<blockquote>
<ul>
<li> This is done because we assume the error will normally be caught</li>
<li> before this method is called.</li>
<li> @param context The context for the preference.</li>
<li> @param preferenceName The name of the preference.</li>
<li> @return The value of the preference, or null if it is not set.<br />*/<br />public static Token preferenceValue(NamedObj context, String preferenceNa\</li>
</ul>
</blockquote>
<p>me</p>
<blockquote>
<p>) {</p>
<p>I'm not sure what the context would be for the "Show this dialog at<br />startup". This is sort of a global context.</p>
<p>Perhaps we should extend VergilPreferences to provide a default global<br />context with a static accessor? Also, it would be nice to have<br />a static method that returns a String:<br />public static String preferenceValueAsString(String preferenceName);</p>
<p>Also, I don't see how I add a new preference? (Edward?)</p>
<p>I'm not particularly wedded to using .xml for the global preferences, but<br />using xml makes sense in this context, where we are setting things<br />like Relation size, Link bend radius and Show Parameters, and we want<br />these things to be inherited and overridden in the model hierarchy.</p>
<p>However, there is quite a bit of appeal to using Plain Old Java (POJ)<br />properties, like what we do with ptII/lib/ptII.properties, which<br />is created by configure and contains POJ properties that<br />are merged in by VergilApplication. POJ properties do not<br />require MoMLParser, so they are more useful for codegen runtime<br />and other small footprint programs.</p>
<p>BTW - Perhaps we should use ptII/lib/ptII.properties for global<br />properties and first load ptII/lib/ptII.properties and then load<br />~/.ptolemyII/ptII.properties (if it exists) so we can override these<br />properties.</p>
<p>Anyway, seems like we have lots of properties systems, we should<br />hash something out and use it.</p>
<p>1) We could extend VergilPreferences:<br />- static accessor without a context<br />- static accessor that returns a String<br />- static setter of new Properties (with automagic save?)</p>
<p>2) Hack up ptII.properties<br />- configure sets properties, but we need to make it easy for<br />users to override<br />- static setter of new Properties (with automagic save?)</p>
<p>3) Hack up the Kepler properties system<br />- Make it useful in Ptolemy only</p>
<p>Comments?</p>
<p>_Christopher</p>
</blockquote> Kepler - Bug #2351 (Resolved): Welcome Window Programmer/Scientist docshttps://projects.ecoinformatics.org/ecoinfo/issues/23512006-02-09T17:47:47ZChristopher Brookscxh@eecs.berkeley.edu
<p>The Welcome Window introProgrammer.htm and introScientist.htm documentation in<br />kepler/configs/ptolemy/configs/kepler/<br />needs to be updated.</p> Kepler - Bug #2349 (New): Actors should have preconditions to test for long runshttps://projects.ecoinformatics.org/ecoinfo/issues/23492006-02-07T18:19:21ZChristopher Brookscxh@eecs.berkeley.edu
<p>It would be nice if there was an easy way to for a model to test for<br />trivial problems before getting far down a long run.</p>
<p>One idea would be to have such actors implement an interface that included a<br />method that the director would run.</p>
<p>We should think about why having actors do more testing in preinitialize()<br />will not work here. For example, if we have an FSM model, do all<br />the actors get preinitialize() called right away? What about the Case actor.</p> Kepler - Bug #2344 (Resolved): Duplicate Actors that read directorieshttps://projects.ecoinformatics.org/ecoinfo/issues/23442006-01-26T20:06:47ZChristopher Brookscxh@eecs.berkeley.edu
<p>Dan wrote:</p>
<blockquote>
<p>Does anyone out there know if there is a difference in the basic<br />functionality of the DirectoryListing actor (author Christopher<br />Hylands, Edward A. Lee) and the FileArrayPrinter actor (author Wibke<br />Sudholt). Both seem to do the same thing (extract file lists from a<br />directory); the DirectoryListing actor seems more full featured (works<br />with URLs). Does the FileArrayPrinter do anything the Directory Listing<br />actors does not?</p>
</blockquote>
<p>Ilkay then wrote:</p>
<blockquote>
<p>AFAIK, they are the same in functionality. There might be some<br />differences between the datatypes/structures they output, and it needs<br />to be consolidated.</p>
</blockquote>
<p>Christopher wrote:</p>
<blockquote>
<p>Ptolemy II uses the DirectoryListing actor as part of the run all<br />demos demo that runs in the display case.</p>
<p>This demo is ptolemy/demo/RunDemos.xml<br />The actor is used in ptolemy/demo/RunDemosInNewProcess.xml<br />It is also used in ptolemy/actor/lib/io/demo/FilePortParamter.xml<br />and ptolemy/actor/lib/test/auto/ExecRunDemos.xml<br />and ptolemy/domains/sdf/test/auto/filePortParameter.xml</p>
<p>I'm not particularly wedded to the DirectoryListing actor, we could<br />modify it to better meet Kepler's needs and then either discard<br />FileArrayPrinter or have it call DirectoryListing but not be listed in<br />Kepler's ui. I'd prefer to discard FileArrayPrinter and move on.</p>
<p>It looks like FileArrayPrinter is used in the following models:<br />/home/eecs/cxh/src/kepler/src/org/resurgence/moml/FileListSequencer.xml:<br /><entity name="File Array Printer" <br />class="org.resurgence.actor.FileArrayPrinter"><br />/home/eecs/cxh/src/kepler/src/org/resurgence/moml/MoleculeSelector.xml:<br /><entity name="File Array Printer" <br />class="org.resurgence.actor.FileArrayPrinter"></p>
<p>Perhaps the authors of these models could use DirectoryListing or<br />else tell me how DirectoryListing should change?</p>
<p>Seems like a bug should be filed for this one. I'm tempted<br />to take it, but I'm slightly over committed.</p>
</blockquote>
<p>Wibke wrote:</p>
<blockquote>
<p>Sorry for not answering earlier, since I am the author.</p>
<p>I assume DirectoryListing and FileArrayPrinter probably do similar things (I<br />think I came across their similarity earlier), though I would need to test<br />in detail. There were, however, some reasons I had for doing a "duplicate" <br />here:</p>
<ul>
<li>This was one of my very first actors in Kepler :-) and so I potentially<br />overlooked the other one (I am a domain scientist by training).</li>
</ul>
<ul>
<li>In the workflows where FileArrayPrinter is used, actually I do not need<br />the URL, but the path. The reason for this is that later there is a lot of<br />command-line calls and processing. And I did not want to always do String<br />processing before.</li>
</ul>
<ul>
<li>For the Resurgence workflows it is very important to be able to transform<br />arrays into sequences of tokens and vice-versa. If that is possible with<br />DirectoryListing, there is probably not much sense to keep FileArrayPrinter.<br />However, I remember another discussion about a Resurgence actor (it might<br />have been about file copying/writing or similar) where it actually turned<br />out that two actors do something similarly, but not identically. The reason<br />for this has been that I always have to make sure that the Resurgence actors<br />work in very particular ways with sequences of tokens.</li>
</ul>
<p>Unfortunately, I am heavily loaded by a different project at the moment, so<br />I will need a bit time to check this. But polishing the Resurgence work is<br />anyhow somewhere on my personal to-do list ...</p>
</blockquote>
<p>I propose that FileArrayPrinter not be available in the Kepler UI, but<br />that the source code remain in the tree so that these models can continue<br />to run.</p>
<p>If someone wants to modify DirectoryListing in a backward compatibile manner,<br />I'm all for it.</p> Kepler - Bug #2318 (Resolved): Copyrights and licenses of subpackages need to be handledhttps://projects.ecoinformatics.org/ecoinfo/issues/23182005-12-14T02:41:42ZChristopher Brookscxh@eecs.berkeley.edu
<p>Just so we don't forget, I'm submitting the copyright issue as a bug.</p>
<p>As a proposed feature, I modified the Kepler configuration.xml and<br />added copyright.htm so that Kepler can take advantage of the Ptolemy<br />II about: facility that helps handle copyright issues.</p>
<p>The problem is that packages such as Ptolemy and Kepler include<br />copyrighted software from various sources. Each package has<br />a different copyright that usually must be displayed somewhere<br />in the release.</p>
<p>I hacked up the about:copyright facilty to help handle this. The<br />current implementation is not perfect, but it helps.</p>
<p>Here's how it works.</p>
<p>If a URL starts with "about:", then code in ptolemy.actor.gui<br />specially interprets it.</p>
<p>"about:copyright" creates a page that includes links to some base<br />copyrights, such as the Ptolemy copyright and the Aelfred copyright.<br />It also looks for particular actors and if those actors are found, it<br />includes a link to the appropriate copyright. One issue here is<br />that searching for the actors can take time, the user might notice a lag.</p>
<p>If the configuration includes a property called _applicationCopyrights<br />then that the value of that parameter is assumed to be an array of<br />records of the form
{{actor="dot.separated.actor.class.name", copyright="relative/url/to/copyright.\<br />htm"}...}</p>
<p>So, if the util.ImageJActor actor is present, then going to about:copyright<br />will include a link to the javadoc and also to imagej-copyright.htm<br />imagej-copyright.htm does not currently exist, but usually this file<br />would include the ImageJ jar file copyright.</p>
<p>One issue as that the link to the javadoc defaults to pointing to the<br />Ptolemy website if the documentation cannot be found. We could add<br />yet another parameter that would send this traffic to the Kepler website.<br />I'll do this later.</p>
<p>So, to try this out, update your Kepler tree, run "ant run-dev" <br />and then at the bottom of the intro.htm, follow the<br />"This software is protected by this license." link.</p>
<p>On the Kepler copyright page, follow the link at the bottom:<br />"Kepler is based on Ptolemy II" <br />This will bring you to the about:copyright page.</p>
<p>On other cool feature is at the bottom of the Kepler copyright page<br />is "Other information about this configuration"</p>
<p>This brings up a page that includes a link (about:configuration) to<br />expand the configuration, which is a good way to quickly test for<br />missing classes. For Kepler, this will not expand to include all the<br />actors the way it does under Ptolemy, but it still has value.</p>
<p>There are also links to expand all the .xml files listed in a file.<br />For example, "about:demos#ptolemy/configs/kepler/intro.htm" <br />will expand all the workflows listed on the Kepler splash page.<br />One can then run all the demos.</p>
<p>Also, "about:links#ptolemy/configs/kepler/intro.htm" will open<br />up all the .htm, .pdf and .xml links on the splash page, which<br />is a good way to check documentation.</p>
<p>In both cases, the expansion is only one level deep, but I use it<br />all the time to check releases.</p>
<p>I don't think this is a perfect solution but it can be used to<br />help address the copyright problem. Further refinement would help.<br />What would need to be done is that for each actor that uses a third<br />party jar file we would need to create a web page that includes<br />the copyright. This takes quite a bit of work, but helps ensure<br />that the copyright is actually shipped with the release.</p>
<p>If this utility is not of interest, then feel free to remove<br />the link at the bottom of copyright.htm.</p>