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

Matthew Brooke brooke at nceas.ucsb.edu
Thu Apr 20 15:03:06 PDT 2006


Christopher -

that was quick! I'm currently in the middle of pulling 
_isPackThreadFinished() from pt.gui.Top, per Edward's request, but as 
soon as i've got that all tested and checked in, i'll give it a shot and 
let you know what happens

thanks!

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


More information about the Kepler-dev mailing list