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

Edward A. Lee eal at eecs.berkeley.edu
Mon Apr 17 21:37:08 PDT 2006


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  



More information about the Kepler-dev mailing list