[kepler-dev] Kepler icon handling (Bug 4903)
Christopher Brooks
cxh at eecs.berkeley.edu
Tue Aug 14 11:29:13 PDT 2012
In Ptolemy, when you drag a MonitorValue into the actor graph pane, the
MoML includes an _icon property
ptolemy/actor/lib/genericsinks.xml contains:
> <entity name="MonitorValue" class="ptolemy.actor.lib.gui.MonitorValue">
> <doc>Monitor and display values</doc>
> <property name="displayWidth" class="ptolemy.data.expr.Parameter"
> value="20"/>
> <property name="_icon" class="ptolemy.vergil.icon.UpdatedValueIcon">
> <property name="attributeName" value="value"/>
> <property name="displayWidth" value="displayWidth"/>
> </property>
> </entity>
genericsources.xml has something similar for Const.
_Christopher
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
> uiSVGIconMappingsBySemanticType.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
>
>
>
>
> _______________________________________________
> 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
--
Christopher Brooks, PMP University of California
CHESS Executive Director US Mail: 337 Cory Hall
Programmer/Analyst CHESS/Ptolemy/Trust Berkeley, CA 94720-1774
ph: 510.643.9841 (Office: 545Q Cory)
home: (F-Tu) 707.665.0131 cell: 707.332.0670
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20120814/7e2e6717/attachment-0001.html>
More information about the Kepler-dev
mailing list