[kepler-dev] Additional menu items
Matthew Brooke
brooke at nceas.ucsb.edu
Mon Jan 23 16:03:32 PST 2006
Just adding a little extra information, in the hope of allaying some of
Edward's and Bertram's fears...
At first glance, the new kepler menu system may appear like a
"branching" of the ptii menu implementation, when in fact it is not - it
is merely a 'view' (in a loose sense) of the ptii menus. It enumerates
all the existing ptii menu items at runtime, and re-uses them,
rearranged (and optionally renamed) - all set via mappings in a
localizable resourcebundle properties (text) file.
This means that if/when new menu items get added to ptii, they are
immediately available to kepler, just by adding the relevant text
mapping to the properties file. The fact that this still requires a
small amount of human intervention is not a bad thing - it avoids the
potentially problematic scenario whereby new ptii menu items
automatically appear in the kepler menus, possibly in places where
Kepler doesn't want them.
m
Christopher Brooks wrote:
> All -
>
> Maybe we should talk some about the general problem of getting changes
> from Kepler in to Ptoelmy on Wednesday, February 8th?
>
> We should discuss it further via email, but we may need to discuss this
> face to face meeting.
>
> I'll demonstrate the new menu Kepler structure to Edward tomorrow at
> Ptolemy group lunch and get his feedback.
>
> In as much as possible, modulo Edward's opinion, I'd like to use the
> Kepler menu structure in Ptolemy II.
>
> Perhaps it would be nice to fold Matthew's menu work in to Ptolemy so
> that Ptolemy can use it? Matthew's work makes it easier to configure
> the menus without necessarily adding a class. We would need to make
> sure that Matthew and the Kepler project get lots of credit for this.
> We could consider creating a third cvs repository with common code,
> but this seems like overkill. I'm also not sure when (if ever)
> would be a good time to move the code. We might just want to change
> the menus in Ptolemy to better match the Kepler menus?
>
> I think the biggest issue with folding changes in to the Ptolemy tree
> is that the new code needs to follow the Ptolemy style guide and be
> well documented. I'm more than willing to work on this.
>
> An issue for the Kepler group is that the Ptolemy style guide is
> probably not what you want.
>
> Another Kepler issue is that we don't want Ptolemy subsuming Kepler
> and getting credit for work done by the Kepler project.
>
> Another issue is that in the past Edward and I have spent a bunch of
> time cleaning up a contribution when maybe our time would have been
> better spent elsewhere. I think the Kepler work is of much higher
> quality than the other contributions I've seen, but it is an issue
> that has come up.
>
> Anyway, I want to be flexible in how we proceed here, so I'm open to
> suggestions.
>
>
> _Christopher
>
> Betram wrotes:
> --------
>
>
> Edward et al:
>
> I am a strong advocate of an incremental approach (and have said so
> before :-). I share the concern that we might be decoupled from new
> developments in Ptolemy and thus should make every effort to make
> "smooth" changes, so that Ptolemy can follow when it makes sense, and
> conversely, we can inherit new developments from Ptolemy..
>
> Easier said than done, I know..
>
> Bertram
>
> >>> On Mon, 23 Jan 2006 09:19:36 -0800
> >>> "Edward A. Lee" <eal at eecs.berkeley.edu> wrote:
> EAL>
> EAL> Instantiate Entity brings up a dialog into which you type a class name
> .
> EAL> The class can defined in Java or in MoML, and the command will create
> EAL> an instance of the class...
> EAL>
> EAL> This mechanism is very useful for experimenting with new actors withou
> t
> EAL> having to include them in a library...
> EAL>
> EAL> The corresponding Instantiate Attribute is also useful (e.g. for crea
> ting
> EAL> an instance of a new director that is under development).
> EAL>
> EAL> Any class in your classpath can be instantiated this way.
> EAL>
> EAL> BTW: One downside of creating a new, parallel menu structure in
> EAL> Kepler is that Kepler will not automatically benefit from capabilities
> EAL> we add to Ptolemy II. This consideration should be balanced against
> EAL> aesthetic considerations... Also, we are more than happy to rearrange
> EAL> menus in Ptolemy II when reasonable suggestions are made...
> EAL>
> EAL> Edward
> EAL>
> EAL> At 06:46 PM 1/22/2006 -0800, Shawn Bowers wrote:
> EAL>
> >> Dan,
> >>
> >> Can you give a little more description of how the "Instantiate Entity"
> >> works? Does this work by pointing Ptolemy at a MoML file (e.g., an "Act
> or
> >> Class") or by pointing it at a java actor class (e.g., "org.kepler. ..."
> ).
> >>
> >> Thanks,
> >>
> >> -shawn
> >>
> >>
> >>
> >> On Sun, 22 Jan 2006, Dan Higgins wrote:
> >>
> >> > Matthew,
> >> > Congratulations on getting the new Kepler menu layout working (and
> >> > the ability to change the configuration)!
> >> >
> >> > However, it looks likes we left out a couple of menu items that I
> >> > just recently learned to appreciate! --- namely 'Instantiate Attribute
> '
> >> > and 'Instantiate Entity' under the 'Graph' menu.
> >> >
> >> > I must admit that I did not understand just what these menu items were
> >> > used for until recently (and I might have suggested to Laura that we
> >> > leave them out in Kepler).
> >> >
> >> > 'Instantiate Attribute' allows the user to add attributes to the
> >> > workflow by name. This allows one to add attributes that are not in th
> e
> >> > Kepler Actor Ontology tree to a workflow! (And we have not included al
> l
> >> > the ones in Ptolemy.) Similarly, 'Instantiate Entity' allows one to ad
> d
> >> > actors; there are many Ptolemy actors/directories that we have not
> >> > included in our actor ontology and I have already been asked by severa
> l
> >> > users how to add such actors to workflows without having to recompile
> >> > the whole Kepler system. It also turns out that whole new actor classe
> s
> >> > can be added using this menu item (i.e. new classes).
> >> >
> >> > So I think these two menu items should be included in the new menu
> >> > layout, probably in the Workflow menu. Maybe Laura will want to change
> >> > the menu item names?
> >> >
> >> >
> >> > Dan
> >> >
> >> > _______________________________________________
> >> > Kepler-dev mailing list
> >> > Kepler-dev at ecoinformatics.org
> >> > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-d
> ev
> >> >
> >> _______________________________________________
> >> Kepler-dev mailing list
> >> Kepler-dev at ecoinformatics.org
> >> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> EAL>
> EAL> ------------
> EAL> Edward A. Lee
> EAL> Professor, Chair of the EE Division, Associate Chair of EECS
> EAL> 231 Cory Hall, UC Berkeley, Berkeley, CA 94720
> EAL> phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
> EAL> eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal
> EAL>
> EAL> _______________________________________________
> EAL> Kepler-dev mailing list
> EAL> Kepler-dev at ecoinformatics.org
> EAL> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-d
> ev
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> --------
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
--
---------------------------------------------
Matthew Brooke, Ph.D.
Marine Sciences Research Building, Room #3407
University of California
Santa Barbara, CA 93106-6150
ph: (805) 893-7108 fx: 805-893-8062
brooke at nceas.ucsb.edu
---------------------------------------------
More information about the Kepler-dev
mailing list