[kepler-dev] Kepler specific Director and ComponentEntity classes and _addIcon()

Thu Apr 20 14:53:47 PDT 2006

Hi Matthew,

Ok, in the spirit of breaking things horribly, I think I have
something that works and would allow us to remove
the Director and ComponentEntity files from exp

I checked in changes to ptolemy and modified Kepler
so that MoMLParser will a method to add an icon.

I added exp/ptolemy/kernel/util/KeplerIconLoader.java
which contains said method

KeplerInitializer sets up MoMLParser to call
KeplerIconLoader.  Currently that code is commented out.

So, to test this:
1) Update ptII and kepler
2) Edit org/kepler/gui/KeplerInitializer.java
and uncomment the call to MoMLParser at the bottom
3) Remove exp/ptolemy/kernel/gui/ComponentEntity.java
and exp/ptolemy/director/Director.java
4) Run "ant clean" or else remove the ComponentEntity
and Director classes

5) Rebuild ptolemy.  I've been using
ant -f build-ptolemy.xml compile
because it is faster

6) ant run-dev

If this works for you, then I'll remove Director
and ComponentEntity and update KeplerInitializer.

Also, I'm not sure if the old attributes will get new icons or not.  I
think we might have to hack MoMLParser up a little.  Let me know if
the attributes are not getting properly iconed.

Also, I'm not sure where we would move 
exp/ptolemy/kernel/util/ComponentEntityConfig.java
Do you have any suggestions?
How about
kepler/actor/gui?

We would need to move KeplerIconLoader as well.

_Christopher

--------

    Christopher:

     > We could delay this.  However, I think Edward sketched out a design
     > that might work.  I could try implementing it and see.
     > [..] This could also solve the icon problem for Attributes.
     > I could install the MoML changes and we could see what happens.

    Won't hurt to try - I'm always up for adventure, as long as we're 
    completely sure it's all working before we commit to cvs. There are 3 
    workflows in cvs that show *all* the actors, so these would be a good 
    test. They are called:

    kepler/workflows/test/all-actors-displayed-part1a.xml
    kepler/workflows/test/all-actors-displayed-part1b.xml
    kepler/workflows/test/all-actors-displayed-part2.xml

     > As per Edward's mail that followed
     > your mail, we are not talking about adding *Icon.xml files.

    I saw that - I kinda thought this was the case, but just wanted to make 
    sure I was on the same page as you guys.

     > I think XMLIcon is a possible fly in the ointment.  I have not
     > looked at it.

    More of an elephant in the ointment, I'm guessing... ;-)
    Although provided the moml changes just add the same attributes that are 
    currently added by ComponentEntityConfig, we might be in luck...

     > It might just work seemlessly.

    Heh - *how* long have you been a developer?? ;o)

    cheers

    m

    ---------------------------------------------
    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
    ---------------------------------------------

    Christopher Brooks wrote:
    > Matthew writes:
    > 
    >> Given the non-trivial issues and potential changes involved, and
    >> given the imminent deadlines for Kepler Beta 1 and 1.0 releases, I'm
    >> soundly of the opinion that we should probably not make any attempt
    >> to actually do any of this until after 1.0; what do you think?
    > 
    > Hi Matthew,
    > 
    > We could delay this.  However, I think Edward sketched out a design
    > that might work.  I could try implementing it and see.
    > It might just work seemlessly.  As per Edward's mail that followed
    > your mail, we are not talking about adding *Icon.xml files.
    > This could also solve the icon problem for Attributes.
    > I could install the MoML changes and we could see what happens.
    > 
    > I was not planning on being at Albuquerque.  Partly a time commitment
    > issue.  I could probably do more for Kepler sitting at home cleaning
    > things up.
    > 
    > I think XMLIcon is a possible fly in the ointment.  I have not
    > looked at it.
    > 
    > _Christopher
    > --------
    > 
    >     At 09:17 PM 4/18/2006, Matthew Brooke wrote:
    >     >If I understand you correctly, you guys are saying we should use the

    >     >*Icon.xml system - is that right? If so, I don't think that's going 
    >     >to work for Kepler; basically, we have about 130 (and counting) 
    >     >icons already defined as standard SVG files - do you mean we'd need 
    >     >to write a *Icon.xml file (which is not SVG, but is ptii-specific) 
    >     >for each one? I'm not entirely sure I'm understanding you correctly,

    >     >so let me know if I'm on the wrong track...
    >     >(keeping up the "train wreck" theme ;-)
    >     
    >     This is not my suggestion...
    >     
    >     What I'm suggesting is that we co-opt the mechanism that supports
    >     the *Icon.xml technique in PtII.
    >     
    >     Specifically, a Kepler-specific icon loader would be registered with
    >     the MoMLParser using a static method (see previous email).  That
    >     icon loader would populate each object that could have a *Icon.xml
    >     file (does this currently include directors?) with a Kepler-specific
    >     subclass of EditorIcon.  That subclass would access your existing
    >     SVG data in whatever form it currently exists and provide the
    >     rendering.
    >     
    >     Edward
    >     
    >     
    >     ------------
    >     Edward A. Lee
    >     Professor, Chair of the EE Division, Associate Chair of EECS
    >     231 Cory Hall, UC Berkeley, Berkeley, CA 94720-1770
    >     phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
    >     eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal  
    > --------
--------