[kepler-dev] problems with annotations

[Matthew Brooke]

Christopher -

 >> 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 
wrong places.

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 
most welcome

Thanks

M

-- 

---------------------------------------------
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.
> 
> _Christopher
> 
> --------
> 
>     
>     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
>     
>     m
>     
>     
>     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
>     http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> --------