Hi Vincent! Thanx for your personal comments on the code! It helped me out a lot, actualy. I think I don't need the GraphicsNodeMouseListener:
My mechanisme for editting svg was previously build on the idea to listen to events of Shapes, sinces these are the ones being actualy clicked. Then I resolved the element linked with the shape with use of the bridge. After that I did some editting on the element and built the gvttree again. With the (for me new) possibility of listening directly to the element itself, I no longer have to use the bridge to resolve the element! Far better! (maybe I still have to use the bridge, to resolve the shape, for highlighting purposes on toplayers on the svgcanvas when the shape is clicked). Best of all, it fixed a problem I had, that I had to add the listeners again after every gvt-rendering/building otherwise, I didn't receive any events anymore... Altogether: cleaner, better. Thanks for your time! Kind regards, Michael. PS Maybe a comment in CVS on the removing (with alternative use) would have answered my question in advance. Vincent Hardy wrote: > Hello Jon and Michael, > > Thanks for your kind words on Batik! As to the event handling modifs, > here is the story.... > > I made the modifications to the event dispatching code about 6 weeks > ago because that code was not consistent. From memory, I remember that > focus events were defined but not fired, mouse events were going both > through the EventDispatch and GraphicsNode listeners and key events > were only dispatched to GraphicsNodes (and not to the EventDispatche > listeners). > > What I did was to remove focus events and make the dispatching go > through the EventDispatcher only. This is enough so that all DOM > listeners can be notified in the end, but it is not enough if you > want to have listeners on individual GVT nodes. > > If you think it is critical to add listeners on individual > GVT nodes, we could add it back. Thanks for entering an RFE in Bugzilla. > > However, I would ask you to consider carefully if you cannot use the > DOM API rather than hooking into GVT directly for events. > > Thanks, > Vincent. > > Jon Burgin wrote: > >>I would like to second Michael's comments. I use GraphcicsNodeMouseEvents. >>It would be a mistake to not consider the effects of removing functionality >>on >>the batik community as a whole. >> >>-----Original Message----- >>From: M. van Veen [mailto:[EMAIL PROTECTED]] >>Sent: Wednesday, April 17, 2002 9:07 AM >>To: [EMAIL PROTECTED] >>Subject: GraphicsNode MouseSupport >> >>Hi! >> >>First of all: Batik rulez! Its great. >> >>The thing I would like to know is whether the GraphicsNodeMouseEvents >>will be supported again in the (near) future (and in the same way?) as >>in Batik 1.1.1? >> >>At the moment I'm working on a project to perform edit functions on SVG >>content read and displayed by Batik. Therefor I used the >>GraphicsNodeMouseEvent functions included by batik 1.1.1 for editting >>with use of a mouse. Unfortunately I noticed that the support for >>mouseevents was removed in Batik 1.5b (from AbstractGraphicsNode CVS >>v1.37 and GraphicsNode CVS v1.34, by Vincent Hardy) since it isn't used >>at the moment(?). >> >>I hope someone can help me with this! >> >>Kind regards and keep up the (very) good work! >> >>Michael. >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
