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

[Christopher Brooks]

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