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

[Sean Riddle]

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 <jones at nceas.ucsb.edu> 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 <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/20120814/6fd30dbf/attachment.html>