[kepler-dev] Additional menu items

Laura L. Downey ldowney at lternet.edu
Tue Jan 24 08:40:53 PST 2006

Sorry been out of town so just seeing this.  I will leave the coding
discussion of re-use and taking advantage of new Ptolemy functionality when
implemented and vice versa from the Kepler perspective, to the architects
and developers.

Specifically to the two menu items that might have been mistakenly removed
in the proposed re-design -- yes, from a design perspective, we can easily
add them back.  And it sounds like with Matthew's implementation, that is
not a major coding issue.

While in general, I think it is a good idea to stay away from computer
science centric terms (such as "Instantiate") because we have a combination
of user groups that will use Kepler (both scientists and programmers), I
don't see the domain scientists or informatics scientists type of Kepler
users really using these items.  They are designed for people with coding
knowledge that will be creating and testing new actors and directors -- so
in that respect it would be programmers using Kepler that would most likely
use the items of Instantiate Entity and Instantiate Attribute.

For the moment, I'll suggest we add these two items to the proposed Tools
menu.  And I would like to also suggest we change "Instantiate Entity" to
"Instantiate Component" since we are calling actors and directors workflow
components in Kepler.

Laura L. Downey
Senior Usability Engineer
LTER Network Office
Department of Biology, MSC03 2020
1 University of New Mexico
Albuquerque, NM  87131-0001
505.277.3157 office
505.610.9657 mobile
505.277-2541 fax
ldowney at lternet.edu

-----Original Message-----
From: kepler-dev-bounces at ecoinformatics.org
[mailto:kepler-dev-bounces at ecoinformatics.org] On Behalf Of Matthew Brooke
Sent: Monday, January 23, 2006 5:04 PM
To: Christopher Brooks
Cc: Kepler-dev at ecoinformatics.org
Subject: Re: [kepler-dev] Additional menu items

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.


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
>    .
>     EAL> The class can defined in Java or in MoML, and the command will
>     EAL> an instance of the class...
>     EAL> 
>     EAL> This mechanism is very useful for experimenting with new actors
>    t
>     EAL> having to include them in a library...
>     EAL> 
>     EAL> The corresponding Instantiate Attribute  is also useful (e.g. for
>    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
>     EAL> we add to Ptolemy II.  This consideration should be balanced
>     EAL> aesthetic considerations...  Also, we are more than happy to
>     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
>     >> works?  Does this work by pointing Ptolemy at a MoML file (e.g., an
>    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
>     >> > 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
>    '
>     >> > and 'Instantiate Entity' under the 'Graph' menu.
>     >> >
>     >> > I must admit that I did not understand just what these menu items
>     >> > used for until recently (and I might have suggested to Laura that
>     >> > 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
>     >> > included in our actor ontology and I have already been asked by
>    l
>     >> > users how to add such actors to workflows without having to
>     >> > the whole Kepler system. It also turns out that whole new actor
>    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
>     >> > layout, probably in the Workflow menu. Maybe Laura will want to
>     >> > the menu item names?
>     >> >
>     >> >
>     >> > Dan
>     >> >
>     >> > _______________________________________________
>     >> > Kepler-dev mailing list
>     >> > Kepler-dev at ecoinformatics.org
>     >> >
>    ev
>     >> >
>     >> _______________________________________________
>     >> Kepler-dev mailing list
>     >> Kepler-dev at ecoinformatics.org
>     >>
>     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>
>    ev
>     _______________________________________________
>     Kepler-dev mailing list
>     Kepler-dev at ecoinformatics.org
> --------
> _______________________________________________
> 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

Kepler-dev mailing list
Kepler-dev at ecoinformatics.org

More information about the Kepler-dev mailing list