[kepler-dev] Re: [SDM-SPA] RFC new directory structure

[Edward A Lee]

At 08:54 AM 3/18/2004 -0900, Matt Jones wrote:
>I've recognized that this merge back with Ptolemy was going to cause some 
>pain.  Right now our developers are not on the Ptolemy team and so it is 
>extremely difficult to make changes to the core Ptolemy classes. Chad and 
>Ilkay and I discussed this, and thought that an interim approach to simply 
>overwrite some Ptolemy java files would work until we could figure out a 
>better way to integrate our work with the Ptolemy work.  This will become 
>even more of an issue as we develop our user interface changes as 
>described in the kepler/docs/dev/screenshots directory, as these will 
>involve a number of significant changes to vergil.

Matt (and others):

I think the right approach to these extensions is a two-step process:

1) Make sure that Ptolemy II has extension points allowing such
    extensions.  Add them if not in the main Ptolemy II tree.

2) Build the extensions.

To give some concrete examples from your kepler/docs/deve/screenshots
directory:

dragDataTable.png and datasetGUIDisplay.png:

    You could do this today by creating a DataSetAttribute that
    extends Attribute and represents the data sets.  In the current
    Ptolemy tree, if you drag an attribute from the library onto
    an icon, it becomes an attribute of the actor owning that icon.
    The icon highlights in white when you drag over it as a visual
    hint that releasing the mouse when the icon is highlighted
    drops the attribute _into_ the target.

This is an example of where the extension points already exist.

An example of where they do not exist, but could be added is
the search engine interfaces that you show in the library.

I think a good way to approach this would be similar to
what we do with Effigy and Tableau factories.  You might have
noticed that if you look inside a Ptolemy II object that is an
instance of ModalModel you get a different editor than if
you look inside one that is a TypedCompositeActor.  This
is because the "configuration" has a list of instances
of TableauFactory that are responsible for opening models.
They are tried in order until one is willing to open the
model.  The last resort is always the TextEditorTableau$Factory
(an inner class of TextEditorTableau), so any unrecognized
file gets opened by the text editor.

We could create a TableauFactory that recognizes a library
and opens a tree view with a search mechanism.  So we are almost
there with current extension mechanisms.

Tableau factories aren't quite what we want, however, because
they open top-level windows.  What we need is for a TableauFactory
to be able to open an editor pane within a window. Then, the
library pane at the left in vergil could have any editor/viewer
at all simply by putting a TableauFactory in the configuration.

This is a small step from where we are, I think... I believe
what we need is simply to augment the Tableau class in ptolemy.actor.gui
so that in addition to creating a Frame, it can alternatively
create a JPanel.  Then the BasicGraphFrame class (which creates
the three-pane view you generally see in Vergil) should use
a TableauFactory to open the library.

I'm not sure exactly of the right factorization here, but I'm
pretty sure that what appears in that left pane should be specified
by the "configuration" file, and should depend on the model
being displayed there...

Comments?

Edward





------------
Edward A. Lee, Professor
518 Cory Hall, UC Berkeley, Berkeley, CA 94720
phone: 510-642-0455, fax: 510-642-2739
eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal