First of all, thanks for the very speedy response!
Thomas DeWeese wrote:
Interactors are intended to be used for modal interaction. If you aren't interested in being modal you can use normal AWT event stuff.
Sorry to be obtuse, but what exactly do you mean by "modal interaction"? Here's what we are doing currently:
Modal interaction, is interaction where once an action starts the action takes over user interaction (gets all events) until the action completes/is terminated.
We allow the user to draw simple lines using the mouse. From MousePressed, through MouseDragged, and until MouseReleased we implement this as AWT Graphics2D drawing (for speed.) Once we see MouseReleased, we take all the collected mouse movements and turn these into SVG <line> elements which are then added to the DOM. In addition to this, we would also like to allow the user to click on embedded URLs in the document, and then launch an external browser in response to this. We found that if we ignore "right button" mouse clicks in our drawing code this allows the event to get passed onto our LinkActivationListener. So the user needs to click the right button to click URLs. This works for us, but I am curious how one would "share" events among many Interactors if there were ever such a need.
What you really have is an interactor that can do one of two things. On mouse down your interactor starts, if the mouse moves you setup to add a line, when the mouse goes up - if there has been motion you want to draw the line - if there has not been motion you want to fire the link under cursor (if there is one).
The point is that there should only ever be one interactor active at a time, it might do different things based on what the actual user action is but it 'has control'. I suppose on interactor might forward events to another but this is assuming a very high level of integration.
2) When my LinkActivationListener launches an external browser in response to a URL click, why afterwards does the JSVGComponent.getUpdateManager() always return null? I am setting my document state to ALWAYS_DYNAMIC in the constructor, and it seems to work fine until I launch the external browser.
I'm guessing some of the normal link handling code is still being called (you can hyperlink between SVG documents in the Canvas) and this code is, as it's first step, shutting down the UpdateManager, your code must head off the replacement of the document however. This may represent a bug in the canvas or your code.
Well the external browser launch is pretty simple (I use JNLP's BasicService.showDocument()). It returns quickly and successfully. However after that point getUpdateManager() forever returns null. Maybe I need to launch the external browser in a specific thread?
So I took a look at the source. linkActivationListers are notifed when a link is traversed but the link is still traversed - so this might be useful if you wanted to create a history log or some such. I think what you want to do is provide a custom SVGUserAgent and implement openLink to forward the link to showDocument. Right now the Canvas tries to open the link and apparently fails - not sure why you don't get notified some how.
3) Is there any advantage to implementing Interactor vs Overlay for creating a "drawing tool" on top of JSVGComponent? It seems that you must implement Interactor in order to see the events, and that Overlay is merely a matter of painting (which you can easily do without implementing that interface- just grab the component's Graphics2D and paint away.) I notice that some of the batik examples implement both (e.g. AbstractZoomInteractor, which extends InteractorAdaptor, but also implements Overlay via an enclosed class.)
I would not recomend grabbing the component's Graphics2D and
painting. This will likely lead to poor behaviour if the area of
document drawn on is updated due to events, etc.
Maybe I didn't describe very well what I was doing. This is just transient drawing in response to mouse drags. Once the mouse is released the AWT drawing done previously is no longer needed as I convert the generated line segments into SVG <line> elements, which are then added to the DOM. It's really not that different from what's being done in AbstractZoomInteractor- when MouseEvents come in the overlay's paint() method is called directly on the component's Graphics2D.
Hmm, this actually has/is a bug. If you bring up samples/3D.svg and use the zoom interactor you get 'dirt' left behind. This is because it currently doesn't register it's self as an overlay with the canvas. I've actually fixed this locally and now the rectangle is solid all the time.
If you use the overlay interface your code will be called when ever the area it covers is repainted due to update events. Try this select some 'animated' text (I like to select the 'batik rules' in samples/extensions/gears.svg).
Since the drawing is transient, no persistent updates are needed.
The problem is that the image can change under your drawing. You may be able to ensure that this doesn't happen (because you control the content) but if it does your painting will be wiped out where the update happens.
Thanks again for your wisdom!
No problem, and good luck!
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
