[kepler-dev] problems with annotations
brooke at nceas.ucsb.edu
Fri Oct 21 13:43:05 PDT 2005
>> BTW, I'm nervous that util.EmptyChangeRequest is required at all.
me too :-) Let me explain what the problem is, and maybe you can
suggest another, more-elegant way to fire such an update...
I've hooked up the Apache Batik SVG rendering framework so that it
handles the rendering of SVG icons. This included overriding
ptolemy.vergil.icon.XMLIcon and diva.canvas.toolbox.SVGParser (code not
yet in CVS) so that when XMLIcon calls SVGParser.createPaintedList(), it
gets back a list contining a diva.util.java2D.SVGPaintedObject (code in
kepler cvs under src/exp/).
However, when the code that draws the actor ports calls
SVGPaintedObject's "getBounds()" method, the svg icon's size is not yet
known (since Batik's rendering process takes a little longer than the
current setup). Consequently, getBounds() returns a default value, and
the ports are initially drawn somewhere on top of the actor, in the
Finally, when Batik has finished rendering, it does a callback to a
listener in XMLIcon, which then needs to somehow make the port-rendering
code redraw the ports in the correct places (by calling
SVGPaintedObject's getBounds() method again, which will now return the
real icon size).
So, EmptyChangeRequest was the only way I could find to fire this port
redraw. Any suggestions as to how it would be better accomplished are
Matthew Brooke, Ph.D.
Marine Sciences Research Building, Room #3407
University of California
Santa Barbara, CA 93106-6150
ph: (805) 893-7108 fx: 805-893-8062
brooke at nceas.ucsb.edu
Christopher Brooks wrote:
> Hi Matthew,
> BTW, I'm nervous that util.EmptyChangeRequest is required at all.
> This could indicate some flaw where ChangeRequests are not being
> created or handled properly.
> I don't have concrete evidence of this, just a gut level feeling.
> would the new util.EmptyChangeRequest class help? If you issue an empty
> change request, are the ports added to the XML? May be worth a try
> Chad Berkley wrote:
> > Hey Matt and Shawn,
> > In looking into the problem of getting the port attributes (mainly the
> > semantic types) to propegate through new kar files, I've run into a
> > fundamental problem with the way PTII handles ports on the canvas. The
> > <port> entity is not actually added to the model until the port is
> > changed. Hence, when you drag an actor to the canvas, if you look at
> > the xml view, there are no moml ports included. This is true until you
> > actually change a port property, then it updates the model with the port
> > information. The problem with this is, even though i'm now adding the
> > port semantic types to the moml in the kar file, they don't show up in
> > shawn's semantic type editor until you actually edit the port. I'm not
> > sure what to do about this. any ideas?
> > Shawn, another bug I found is that the sms system isn't using the
> > semanticTypeX properties that i had in the actor metadata. Instead,
> > it's creating another property called _semType. Because of this, we're
> > ending up with two annotations per actor. This will probably get fixed
> > when you update the sms stuff, right?
> > chad
> > _______________________________________________
> > Kepler-dev mailing list
> > Kepler-dev at ecoinformatics.org
> > http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
More information about the Kepler-dev