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

Edward A. Lee eal at eecs.berkeley.edu
Tue Aug 14 11:36:17 PDT 2012


We deliberately keep icon information separate, as much as
possible, from actor definitions.  There are two main mechanisms.
The first, used by Const, is to include the icon in the Vergil
library.  The file $PTII/ptolemy/actor/lib/genericsources.xml
has this in it:

<entity name="Const" class="ptolemy.actor.lib.Const">
<doc>Create a constant sequence.</doc>
    <property name="_icon" class="ptolemy.vergil.icon.BoxedValueIcon">
       <property name="attributeName" value="value"/>
       <property name="displayWidth" value="60"/>
    </property>
</entity>

When you drag a Const in the from the library, it will come
with an instance of BoxedValueIcon inside it.

Monitor value also uses this mechanism.

The other commonly used mechanism is to define an XML file
named ConstIcon.xml, and to put it in the same directory as
Const.java.  I think this second mechanism is completely
bypassed by Kepler, so most of the icons we create are never
seen in Kepler...

I personally wish we hadn't forked the icon rendering
in Kepler, but I guess it was partly a branding issue
and partly an aesthetic issue. But that's where we are...

Edward



On 8/14/12 11:25 AM, Sean Riddle wrote:
> 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
> <mailto: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
>     <mailto: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 <mailto: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
>                 <mailto: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 <mailto:Kepler-dev at kepler-project.org>
>         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 --------------
A non-text attachment was scrubbed...
Name: eal.vcf
Type: text/x-vcard
Size: 330 bytes
Desc: not available
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20120814/f6c48967/attachment.vcf>


More information about the Kepler-dev mailing list