[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