I'm still a little puzzled as to the nature of the bypass that Constant and MonitorValue apparently use. If anyone has any more details, I would love your input. Neither actor appears to explicitly create an "_icon" attribute, which would customize the icon. There are no obvious suspects in the Java classes, nor in the XML declarations for the classes.
- Sean On Mon, Aug 13, 2012 at 4:39 PM, Matt Jones <[email protected]> wrote: > Kepler has a default icon that it uses if a valid mapping can't be found, > so that is its fallback. There is already a config setting that allows you > to let the ptolemy behavior through for particular actors. That was added > to accomodate the dynamic actors like Monitor and Constant to allow them to > show their values. So, you should be able to configure others to allow > that too without any new code. Look at Monitor to see how it is configured > for an example. > > Matt > > > On Mon, Aug 13, 2012 at 2:19 PM, Sean Riddle <[email protected]> wrote: > >> Well, the problematic attributes are the ones that Kepler displays >> appreciably differently than Ptolemy, especially if it is to the detriment >> of the usability of the actor. If you meant how will I actually find them >> in the codebase, I'm not particularly sure; I was planning on just >> classifying them as the problems are noticed. >> >> If a mapping for an icon is not found in the configuration, what does the >> system do? Does it fall back to the Ptolemy system? If not, how would >> people feel about me adding a sentinel value that can be used in the >> configuration files to specify that the Ptolemy icon generation system >> should be used instead? >> >> - Sean >> >> >> On Mon, Aug 13, 2012 at 2:54 PM, Daniel Crawl <[email protected]>wrote: >> >>> >>> Hi Sean, >>> >>> Icons are set in ComponentEntity.addSVGIconTo() based on the LSID, >>> class, or semantic type. This uses the configuration files >>> uiSVGIconMappingsByLSID.xml, uiSVGIconMappingsByClass.xml, and >>> uiSVGIconMappingsBySemanticTyp**e.xml to determine the icon. >>> >>> How would you identify problematic attributes? Maybe only attributes >>> that are Parameters should have their icons changed? >>> >>> --dan >>> >>> >>> >>> On 8/13/12 2:37 PM, Sean Riddle wrote: >>> >>>> Hi all, >>>> >>>> I'm taking a look at bug 4903, which is Kepler displaying certain icons >>>> incorrectly. It appears that the problem comes down to Ptolemy using the >>>> normal, standard method of icon determination, and Kepler using a custom >>>> method that sometimes gives erroneous results - this is implemented in >>>> org.kepler.gui.KeplerXMLIcon in the gui module. Manually disabling the >>>> custom icon rendering class allows me to instantiate >>>> MonitorReceiverContents and get the expected icon as in Ptolemy. >>>> >>>> I'm a little unsure about how to implement a fix to this. Is there a >>>> way, as with the _alternateGetMoml attribute, to set the custom icon >>>> rendering on a per-class/LSID basis? If so, disabling it for problematic >>>> attributes would be a simple fix. On the other hand, if there's no way >>>> to customize the behavior for certain actors, I could still modify >>>> KeplerXMLIcon such that it performs like the XmlIcon Ptolemy class for >>>> any problematic attributes. I'm going to poke around assessing the >>>> viability of the latter approach, but if anyone knows this part of the >>>> code better, feel free to suggest something different. >>>> >>>> Thanks, >>>> >>>> Sean >>>> >>>> >>>> ______________________________**_________________ >>>> Kepler-dev mailing list >>>> [email protected] >>>> http://lists.nceas.ucsb.edu/**kepler/mailman/listinfo/**kepler-dev<http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev> >>>> >>>> >>> >> >> _______________________________________________ >> Kepler-dev mailing list >> [email protected] >> http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev >> >> >
_______________________________________________ Kepler-dev mailing list [email protected] http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
