[kepler-dev] Kepler icon handling (Bug 4903)

Matt Jones jones at nceas.ucsb.edu
Mon Aug 13 16:39:01 PDT 2012


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 <swriddle at gmail.com> 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 <danielcrawl at gmail.com>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
>>> Kepler-dev at kepler-project.org
>>> http://lists.nceas.ucsb.edu/**kepler/mailman/listinfo/**kepler-dev<http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev>
>>>
>>>
>>
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at kepler-project.org
> http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20120813/bcd0bb87/attachment-0001.html>


More information about the Kepler-dev mailing list