Kepler

I merged data.expr.Constants by hacking in an initialization class at
kepler.gui.
I removed data.EDoubleToken because it was not used.
Edward and I will handle modifying BaseType and TypeLattice so that types
can be added.
Shawn removed EditParametersDialog.

I'll take this bug.
I was able to move a few files, see below.
I can also probably move the DBConnectionToken out.

After that, we start to run in to more SVG work. The problem is that we don't
want to require Ptolemy to have the Batik SVG render. Next up is Director.

diva.util.java2d -- Done!
SVGPaintedObject
SVGRenderingListener
Used by exp/ptolemy/vergil/icon/XMLIcon
I moved these diva classes in to Ptolemy by creating a
subdirectory called diva.util.java2d.svg
$PTII/configure checks for batik and does the right thing.

ptolemy.actor
Director.java - Call ComponentEntityConfig.addSVGIconTo()
I think we could use reflection in an initializer or something.

I removed these, they were unused:
  ModelDependencyGraph.java
  NameTrueFalseQuery.java
  ProvenanceExecutionListener.java
  SmartRerunManager.java
  StreamActor.java

ptolemy.actor.gui -- not sure
TableauFrame.java - Has menu changes

ptolemy.data -- I'll rewrite DBConnectionToken to be like
ptolemy.data.type.test.TestToken
DBConnectionToken.java - New Token
ptolemy.data.type -- needs extension points
BaseType.java - Adds DBConnectionToken
TypeLattice.java - Adds DBConnectionToken

ptolemy.kernel -- not sure
ComponentEntity.java

ptolemy.kernel.util:
ComponentEntityConfig.java (new class, not in Ptolemy)
Used by
exp/ptolemy/actor/Director.java
exp/ptolemy/kernel/util/ComponentEntityConfig.java
exp/ptolemy/kernel/ComponentEntity.java
exp/ptolemy/vergil/icon/XMLIcon.java
and other places

StaticResources.java  (new class, not in Ptolemy)
    Used by
      exp/ptolemy/actor/gui/TableauFrame.java
      exp/ptolemy/kernel/util/ComponentEntityConfig.java
      exp/ptolemy/vergil/basic/BasicGraphFrame.java
      exp/ptolemy/vergil/basic/MenuMapper.java
      exp/ptolemy/vergil/icon/XMLIcon.java
    and other places

ptolemy.util --
OrderedResourceBundle.java -
Used by exp/ptolemy/vergil/basic/MenuMapper.java and other places

ptolemy.vergil.actor -- not sure
ActorController.java
IOPortController.java

ptolemy.vergil.basic -- could be merged except UI changes not acceptable
BasicGraphController.java
BasicGraphFrame.java
ContextMenuFactoryCreator.java
GetDocumentationAction.java
MenuMapper.java
ParameterizedNodeController.java

ptolemy.vergil.icon -- not sure if UI changes acceptable
XMLIcon.java - SVG

ptolemy.vergil
VergilApplication.java
I think this code has threading problems and should be fixed
For example, it looked like the TableauFrame._getDefaultIconImage()
was being called in the wrong thread. See
http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2343

I removed Director and ComponentEntity.
I'm working on VergilApplication.

I merged in several files from kepler into ptII.
See kepler/src/exp/expfiles-merge-notes.txt

To merge more files, PortEvent and PortEventListener need
to be renamed to IOPortEvent and IOPortEventListener.

Another issue is that some of the remaining changes
require the apache logging facility, which should go into
the tree, but probably not right now, as I'm shipping
Ptolemy II 7.0.beta next week.

PortEvent and PortEventListener have been renamed.

I merged in IOPortEvent and IOPortEventListener.

I also updated ptolemy/domains/pn/kernel/NondeterministicMerge
with Kepler specific changes: we now have a c'tor that takes a
Workspace argument.

core/src/ptolemy/kernel/util
ComponentEntityConfig.java - not present in Ptolemy, no need to merge
KeplerIconLoader.java - not present in Ptolemy, not need to merge

I created kepler/util/src/ptolemy/README.txt, see below:

--start--

util/src/ptolemy/domains/sdf/kernel
SDFDirector.java - This should be removed asap.
r16847 | aschultz | 2009-03-04 16:52:41 -0800 (Wed, 04 Mar 2009) | 1 line
experimenting with SDFDirector override: setting default iterations
to be 1

Perhaps we should have a property, such as
   ptolemy.ptII.SDFDefaultIterations that is read and then SDFDirector
   would have a private static variable that is set once by reading
   the property?

util/src/ptolemy/vergil/actor
ActorController.java - lots of changes
ActorEditorGraphController.java - not so many changes, some code in
addToMenuAndToolbar that adds org.kepler.gui.ViewManager:

JPanel ddHolder = new JPanel(new BorderLayout());
        ViewManager vman = ViewManager.getInstance();
        JComponent vsel = vman.getViewSelector( getFrame() );
        ddHolder.add( vsel, BorderLayout.EAST );
        toolbar.add( ddHolder );
     Maybe we can check for something in the configuration or something?

ActorGraphFrame.java - Trival changes, calls to background
      commented out?

r16844 | aschultz | 2009-03-04 15:17:11 -0800 (Wed, 04 Mar 2009) | 2 lines

Experiment with KeplerGraphFrame.BACKGROUND_COLOR  and  TabManager.BGCOLOR
   Overriding ActorGraphFrame to avoid _setBackground during repaint

util/src/ptolemy/vergil/basic
BasicGraphController.java - lots of changes
MenuMapper.java - not in Ptolemy, so no need to merge

--end--

Also, in the ptII tree, ptolemy.kernel.util.StaticResources needs
to be fixed or removed because it uses UI code. The kernel should
not have UI code in it.

Kepler's classpath override of ptolemy.vergil.basic.BasicGraphFrame has been removed from Kepler's util module. These changes now reside in a subclass of ActorGraphFrame at org.kepler.KeplerGraphFrame where the methods of Ptolemy's BasicGraphFrame are directly overridden.

See bug # 3977, Devlop test for ptII overrides in the system

util/src/ptolemy/README.txt
says:

Below are files that are in a ptolemy package, but checked in to kepler

util/src/ptolemy/vergil/actor
ActorController.java - lots of changes

ActorGraphFrame.java - Trival changes, calls to background
      commented out?

r16844 | aschultz | 2009-03-04 15:17:11 -0800 (Wed, 04 Mar 2009) | 2 lines

Experiment with KeplerGraphFrame.BACKGROUND_COLOR  and  TabManager.BGCOLOR
   Overriding ActorGraphFrame to avoid _setBackground during repaint

util/src/ptolemy/vergil/basic
BasicGraphController.java - lots of changes
MenuMapper.java - not in Ptolemy, so no need to merge

--end--
About ActorGraphFrame.java, perhaps this file could be removed?
One way to set the background is
covered in _printPDF() in ptolemy/actor/gui/MoMLApplication.java
Maybe the code in this method could be used?

About the other classes, one thing to do would be to merge with
the latest in the tree. I'll go ahead and do this

In the conference call on 4/21/09, Christopher agreed to take a pass at this and I (chad) will finish off whatever he doesn't get to.

ptolemy/vergil/actor/ActorController.java has been updated.
A ListenToActor action was added to the version in the ptII tree.

The menus in uiContextMenuMappings_en_US.properties were also updated.

Running " ant clean-module -Dmodule=ptolemy" or "ant clean-all"
will be necessary, as trees will have old copies of ActorController.class
and the actor context menus will be missing the entries for Ports and Units.

After the merge of ActorController, Open Actor and Convert to Class are no longer in the context menu for actors.

Open Actor and Convert to Class are in the actor context menu for me
in a clean checkout, after
mkdir kepler
cd kepler
svn co https://code.kepler-project.org/code/kepler/trunk/modules/build-area
cd build-area
ant change-to -Dsuite=kepler
cd ../loader
svn update -r 17442
cd ../build-area
ant run

Doing an ant clean-all might be necessary to pick up the changes to
the context menu mappings file.

I have changes almost ready to be checked in to remove the Kepler specific
version of BasicGraphController - I still need to fix a problem with Frames.

I've made changes and removed util/src/ptolemy.
One remaining issue is ActorGraphFrame, see the discussion below.
I've gone ahead and removed the duplicate copy of ActorGraphFrame because
I don't see the problem, but I believe that this change could cause problems
so I'm not closing this bug.

If the recent changes I made cause problems with menus, please let me know.

Aaron wrote:

Yes, having the call to _setBackground() in the repaint methods of
ActorGraphFrame was a problem because we are setting the background
of the canvas directly from the KeplerGraphFrame class (
_rightComponent.setBackground(BACKGROUND_COLOR); ) and not using the
ptolemy entity configured background color preference that the
ActorGraphFrame._setBackground() method uses. So every time the canvas
repainted the background color would change back to white after the initial
color was set to Gray by KeplerGraphFrame. The only reason for setting the
canvas background to gray is actually to match the swing tab color on
MacOSX. In this l&f I was not able to find a way to adjust the background
color of the header part of the tab so any other color than Gray looks funny
on MacOSX. Probably we just need to figure out how to properly use the
enitity configured background color preference thingy and we could survive
without those changes.

Thanks,
Aaron

Christopher Brooks wrote:

Hi Aaron,
I'm trying to clear up the files in Kepler that duplicate Ptolemy.

One file is util/src/ptolemy/vergil/actor/ActorGraphFrame.
The change was:

r16844 | aschultz | 2009-03-04 15:17:11 -0800 (Wed, 04 Mar 2009) | 2 lines

Experiment with KeplerGraphFrame.BACKGROUND_COLOR and TabManager.BGCOLOR
Overriding ActorGraphFrame to avoid _setBackground during repaint

The diff is:
bash-3.2$ diff rwb util/src/ptolemy/vergil/actor/ActorGraphFrame.java ptolemy/ptolemy/vergil/actor/ActorGraphFrame.java
3c3
< Copyright (c) 1998-2008 The Regents of the University of California.
--

Copyright (c) 1998-2009 The Regents of the University of California.

87c87
< * @version $Id: ActorGraphFrame.java 52510 2009-02-26 17:52:38Z cxh $
---

• @version $Id: ActorGraphFrame.java 53042 2009-04-10 20:31:21Z cxh $

376,377c376
< // FIXME: This is one of two Kepler specific lines in this code
< //_setBackground();
---

_setBackground();

382,383c381
< // FIXME: This is one of two Kepler specific lines in this code
< //_setBackground();
---

_setBackground();

Are these changes required? What happens if we don't have them?

Just noticed something weird about this. If you draw a rubber-band box around the actors, the selection is shown, but if you just click on them the selection color is not shown.

A thought as well...I'm not sure how hard this would be, but it'd be really nice if, on composites, there was an "open actor in new window" and an "open actor in tab" choice. Maybe I should add that as a feature request. Aaron, how hard would that be?

Enabling multiple tabs to be opened in one window is a feature we already identified and mocked up as part of the reporting work. I think it would be a great addition, and would help with the complaints we receive about not being able to kep track of all of the windows that Kepler opens. That said, this part of the reporting subsystem was deferred to simplify the implementation, so I think it would be good to open a separate bug for it.

Hi Chad, I am currently under the impression that it would be a substantial effort to open multiple actor canvases in the same GraphFrame but in separate tabs. Partly because the view/tab mechanism we have implemented thus far is extremely simplistic and not very conducive to a dynamic environment of tabs coming and going (they're currently all hard coded in the configuration files). Also because the existing vergil code assumes that there is one canvas per graph frame it may not be as easy as short circuiting all of the menu actions depending on which actor tab has focus at the time, my feeling (although I haven't dug into details) is that there would be many problems if/when we tried to do this...

(In reply to comment #15)

Just noticed something weird about this. If you draw a rubber-band box around
the actors, the selection is shown, but if you just click on them the selection
color is not shown.

A thought as well...I'm not sure how hard this would be, but it'd be really
nice if, on composites, there was an "open actor in new window" and an "open
actor in tab" choice. Maybe I should add that as a feature request. Aaron,
how hard would that be?

There are selection and highlighting issues that should be addressed before
this bug is closed.

I'm closing this.
The highlight issue was fixed by modifying KeplerGraphTableau to extend Tableau
and then modifying WorkflowTypeCheckerDialog to cast something to Tableau.

Original Bugzilla ID was 2321