[kepler-dev] Kepler specific Director and ComponentEntity classes and _addIcon()
Matthew Brooke
brooke at nceas.ucsb.edu
Wed Apr 19 10:12:10 PDT 2006
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