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

Matthew Brooke brooke at nceas.ucsb.edu
Tue Apr 18 09:47:46 PDT 2006


Hi Christopher/Edward -

A couple of thoughts and some additional info:



 > Also, this means that every Director and ComponentEntity would
 > have to have a BatikEditorIcon attribute in the MoML file.

We are specifically trying not to include icon descriptions or 
assignments in the MOML files (or in *Icon.xml files, or hard-coded in 
java), since it presents a maintenance problem for us (if/when icon 
assignments change, older models will still show the old assignments). 
This obviously becomes a larger and larger problem as models proliferate.

We therefore have all our icon assignments in 2 text files - one has 
icons assigned by classname, and the other assigned by LSID. When 
Director or ComponentEntity make the call to:

  ComponentEntityConfig.addSVGIconTo(this);

the method does a lookup to try to match the specific subclass (ie the 
actor or director) by LSID, and then by classname. It then sets a 
ConfigurableAttribute (called "_svgIcon") on the actor/director, which 
is subsequently used by the Batik rendering system. (We don't change the 
existing "_iconDescription" attributes, so these are still present as 
a"fallback" in case anything goes wrong with the assignments.)

Having this centralized system is important to us, because it provides a 
level of decoupling between the models and their visual representations 
- we can make changes to icon assignments, and even completely change 
out *all* the icons at once if needed, and thus "re-skin" workflows 
entirely.


 > 4) My previous idea, where we have some code that sets the Iconable
 > class that gets called.  This results in one method being
 > added to Directory and ComponentEntity.

Cool idea, but we'd still need to introduce an "Iconable" interface into 
ptii (maybe I'm just missing the point ;-).  To be completely Kepler 
agnostic, we'd have to use your reflection solution, I think?


Just some extra stuff to add to the mix...

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:
> Interesting idea.  We could create a subclass of EditorIcon called
> BatikEditorIcon that would do this.
> 
> However, how would we handle changing the icons of preexisting models?
> I suppose we could use the MoMLFilter.  This would slow down the Kepler
> a little, but would not be noticable.
> 
> Also, this means that every Director and ComponentEntity would have to
> have a BatikEditorIcon attribute in the MoML file. This will increase
> model file size a certain amount, say 10%?
> 
> Besides my proposal below, an alternative that is more in keeping with
> _iconDescription would be to either modify _iconDescription so it
> calls the addSVGIcon method or add a static text valued attribute that
> named the class that was to be called.  I think this would be
> definitely pollute Director and ComponentEntity with more UI code, but
> it would also be more lightweight (smaller MoML files).
> 
> We really need to do something, having separate copies of these files
> is not maintainable.  I keep fixing problems in Ptolemy and then
> I or someone else has to update the copies in Kepler.  
> 
> To recap, I see several solutions
> 1) Do nothing - we keep updating these files by hand
> This is not maintainable.
> 
> 2) Hack in Kepler specific code that calls ComponentEntityConfig
> I have this implemented in my tree, there is a static initializer
> that uses reflection to see if ComponentEntityConfig exists 
> and if it does then each _addIcon() method calls  
> ComponentEntityConfig.addSVGIconTo(this);
> The problem here is that it is somewhat hardwired and ugly.
> 
> 3) My new idea, which would be to somehow modify _iconDescription so
> that we can invoke a method that creates the icon.  We could either
> have another attribute, say _iconFactory or we could add a field It
> would be nice to be able to change the icon once for all Directors and
> once for all ComponentEntities, so I'd like to create a static method
> that allows the user to override what text _addIcon attaches.  Perhaps
> we could attach the BatikEditorIcon here?  Or, _iconDescription could
> take a class name and method name to be invoked somehow.  This has the
> advantage of being done once each for Director and ComponentEntity.
> 
> 4) My previous idea, where we have some code that sets the Iconable
> class that gets called.  This results in one method being
> added to Directory and ComponentEntity.
> 
> 5) Your idea of using EditorIcon here.
> This would bulk up the Kepler models a little, say 10%?
> Also, current models would need a filter.
> 
> I'm still feeling that I'd prefer to see #4, adding setIcon().
> 
> What do you think?  I agree that #4 is not perfect but it seems like
> less work and not much uglification of the UI.  At least I'm staying
> out of NamedObj :-)
> 
> My goal here is to help the Kepler folks with some UI problems.  In my
> mind, it should not be necessary to override Ptolemy classes, it 
> should be possible to extend classes or use attributes like
> EditorIcon.
> 
> A good example of this is that for the DBConnectionToken class it was
> not necessary to override ptolemy.data.type.BaseType, instead I 
> used an inner class like what we do for
> ptolemy.actor.lib.security.KeyToken. 
> 
> If a Ptolemy class is being overridden with a copy of a class, it is
> either a bug in Ptolemy or a bug in Kepler and it should be fixed
> so as to avoid problems.
> 
> _Christopher
> 
> --------
> 
>     
>     There is no need to modify any Java class to change the icon...
>     Any attribute (including directors) that contains an instance of
>     EditorIcon or any subclass of EditorIcon will defer to that class
>     to render the icon.
>     
>     So why can't the Kepler configuration just include such an
>     attribute in every director in the director library?
>     
>     We have tried to keep the support in the kernel for visual rendering
>     to an absolute minimum... At most some text-valued attributes,
>     like _iconDescription. In retrospect, even this was probably a
>     mistake.  Icons should be controlled by attributes contained
>     by the object being represented by the icon.
>     
>     Edward
>     
>     
>     At 09:21 PM 4/17/2006, Christopher Brooks wrote:
>     >Hi Edward,
>     >
>     >I'm looking at folding in the Kepler copies of Director
>     >and ComponentEntity.  The reason to fold these in is
>     >to avoid code duplication and reduce maintenance.
>     >
>     >Both of these classes have _addIcon methods like:
>     >
>     >     private void _addIcon() {
>     >
>     >       //simple Icon:
>     >       _attachText("_iconDescription", "<svg>\n"
>     >                   + "<rect x=\"-30\" y=\"-20\" width=\"60\" "
>     >                   + "height=\"40\" style=\"fill:white\"/>\n"
>     >                   + "<polygon points=\"-20,-10 20,0 -20,10\" "
>     >                   + "style=\"fill:blue\"/>\n" + "</svg>\n");
>     >
>     >       try {
>     >         ComponentEntityConfig.addSVGIconTo(this);
>     >       } catch (Exception ex) {
>     >         //ignore exceptions - they just mean that the
>     >         //default icon will be used, as defined above
>     >       }
>     >     }
>     >
>     >In this case,
>     >         ComponentEntityConfig.addSVGIconTo(this);
>     >is a Kepler static method that takes a NamedObj as an argument
>     >and adds an SVG icon.  So, we need some way for Kepler
>     >to override the icons without subclassing Director.  We
>     >can't subclass Director here because SDFDirector etc all
>     >extend Director and they would not extend our new class that
>     >had the custom Kepler icons.
>     >
>     >I could hack some Kepler specific hack that used reflection to look
>     >for a specific class that added the icon, but I think it would be
>     >better to add methods that named a class that on which we invoked a
>     >method that would add the Icon.
>     >
>     >Unfortunately, it looks like this would go in NamedObj and thus would
>     >be present for all NamedObjs.  I think it would be better for Director
>     >and ComponentEntity to have a setter that sets a class on which we can
>     >call an addIcon().  Yes, this is a little bit of code duplication, but
>     >it is not horrible.  Perhaps we could have Director and
>     >ComponentEntity implement a IconableFactory(?) interface that just has
>     >the setIconable method.
>     >
>     >
>     >Director and ComponentEntity would both get
>     >     setIconable(Iconable iconable) {
>     >         _iconable = iconable
>     >     }
>     >     private static Iconable _iconable;
>     >
>     >     private void _addIcon() {
>     >         _attachText("...");
>     >         if (_iconable != null) {
>     >             try {
>     >                 _iconable.addIcon(this)
>     >             } catch (Exception ex) {
>     >                 //ignore exceptions - they just mean that the
>     >                 //default icon will be used, as defined above
>     >             }
>     >     }
>     >
>     >ComponentEntityConfig would implement Iconable and have
>     >     public static addIcon(NamedObj) {
>     >         ....
>     >     }
>     >The KeplerInitiailizer would call setIconable() for
>     >Director and ComponentEntity and set it to ComponentEntityConfig.
>     >
>     >Whattya think?  Do you have any ideas?
>     >
>     >Director and ComponentEntity should not really have icon specific code
>     >in them, but they already have _attachText() calls.
>     >
>     >_Christopher
>     
>     ------------
>     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  
> --------
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev


More information about the Kepler-dev mailing list