Bug #2345
closedActor Library classname/icon mapping problems
0%
Description
This pertains to running Kepler with the new icons enabled
(to do so, edit the file configs/ptolemy/configs/kepler/uiSettings.properties
and change the SVG_RENDERING_IS_BATIK property to:
SVG_RENDERING_IS_BATIK=true, then do a clean build)
---------------------
1) First time Kepler is run after a clean build (deleting kepler/kar,
kepler/build and ~/.kepler), expand the actor ("components") tree until the
"Parameter" actors are showing ("ColorParameter", FileParameter" etc). Drag
ColorParameter to the canvas, and the icon shows up as a colored dot.
2) Now stop kepler, then re-run it again (non-clean run). Repeat the above, and
this time, the icon on the canvas for ColorParameter is a teal rectangle (ie the
default icon)
3) Also, in a previous incarnation, the small icons in the tree were correctly
assigned by classname (showed up as a teal dot) - now, that seems to be broken,
and all just use the default blank rectangle (not related to whether it's a
clean run or not). Sorry I don't have any more-concrete info on when this
stopped working.
The icons for those actors are currently assigned by classname (see
configs/ptolemy/configs/kepler/uiSVGIconMappingsByClass.properties), and I think
these changes in behavior is something to do with how the parameters are
instantiated - we previously saw (and Chad fixed) issues similar to this in the
ActorMetadata class, but for Directors - which were not getting instantiated as
the correct class (Director), rather as a superclass, I believe.
Let me kow if you need any more info
Related issues
Updated by Matthew Brooke almost 19 years ago
In order to illustrate what the icons should look like, I have assigned the
icon by LSID (instead of by classname) for the "PortParameter", which is showing
the correct icon.
All the parameters should show this same icon - in the tree and on the canvas -
instead of the ones currently showing.
Updated by Matthew Brooke almost 19 years ago
moved target to beta1 - need this fixed asap if poss, since it blocks bug #2324
Updated by Matthew Brooke over 18 years ago
no need to fix - no longer causes problems since Christopher moved the location of the icon-assignment code