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 <[email protected]
<mailto:[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]
<mailto:[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] <mailto:[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
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
[email protected]
<mailto:[email protected]>
http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
_______________________________________________
Kepler-dev mailing list
[email protected]
<mailto:[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
--
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
_______________________________________________
Kepler-dev mailing list
[email protected]
http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
