A related issue is that of cursor control. The scroll bar I'm working on is one example. When the user presses on the scroll bar, a grabbing event listener that stops propagation is registered on the document root to ensure that it gets mouse events until the release - independent of where the mouse is located. During that time the cursor should also be set to indicate that the scoll operation is still in effect. For example, you don't want the cursor to change to a text cursor when moving over text - the text isn't currently selectable while the scroll bar listener is taking all the events. Trying to do this by adding a huge transparent rectangle over everything else seems like a hack/workaround, rather than a robust solution.
I think you are being too hard on the transparent rectangle solution. This has a long history in UI engines (lots of X11 apps used this approach to 'deaden' areas of the UI). Allowing an application to truely grab mouse events can be problematic in a Browser context - easy denial of service attack.
Thanks for the patch, the dummyText node does look pretty bad.
BTW it is much better to submit patches using diff, the easiest thing to do if you are working off CVS is 'cvs diff' I use 'cvs diff -wu' which ignores whitespace differences and produces what is called a 'unified context diff' which some find easier to read. These can then be fed directly into a program like 'patch' to 100% accurately reproduce the changes.
----- Original Message ----- From: "Denis Bohm" <[EMAIL PROTECTED]>
To: "Batik Users" <[EMAIL PROTECTED]>
Sent: Friday, September 05, 2003 3:39 PM
Subject: Re: grab DOM event?
Getting a mouseout event doesn't really help me. I don't want to
cancel
the
operation based on mouseout as the user could drag the mouse back into
the
window and then release. I really need to get a mouseup and I don't
seem to
be getting one right now. Should I get a mouseup with a null
relatedTarget?
Well if you got anything it would be a mouseup with a null 'target' but such a thing doesn't exist. I understand your desire but it's also not 100% clear to me that we should deliver such an event (first off I think it would likely break lots of code that assumes there will always be a target). Anyone else care to weigh in with opinions? I don't care for the target document or root because it just doesn't make sense. Any what would you use for clientX/Y? values outside of the viewport? These of course of 'cleaness' arguments where as you have a solid need.
Anyway contributions are always welcome - if done well it would probably be accepted.
I made two changes to my copy of the Batik source, shown below, and now
all
mouse events are processed and sent to the root if there is no target
found.
It now works well in my application. When the user presses on a slider
then
I can register a grab listener at the root that stops propagation and processes all events until the user releases the mouse or cancels the operation - even when they drag outside the JSVGCanvas, etc. It actually simplifies the code and removes an odd text dummyNode that I noticed
caused
a null pointer problem in some other area because it events were being dispatched to the node, but it wasn't part of the document.
However, if people have written code to rely on only getting events to the root when the mouse is over an element then this will effect that code. I wonder if that is common. I looked around at some interactive SVG
examples
on the web. Seemed like most of them had the same problems that my code used to have and some were trying the same kind of "tricks" like adding invisible root elements, etc, which don't solve all the problems.
Seems to me the ability to get all events is essential to being able to create interactive interfaces using SVG.
What do others think?
Denis
---
BridgeEventSupport:
protected void dispatchMouseEvent(String eventType, Element targetElement, Element relatedElement, Point clientXY, GraphicsNodeMouseEvent evt, boolean cancelable) { if (targetElement == null) { // -denis- dispatch to document if no target // return; targetElement =
context.getDocument().getDocumentElement();
}
AWTEventDispatcher:
// protected GraphicsNode dummyNode = new TextNode(); ... // In all cases, dispatch the original event // -denis- dispatch to root if no target // if (node != null) { gvtevt = new GraphicsNodeMouseEvent(node != null ? node :
root,
evt.getID(), evt.getWhen(), evt.getModifiers(), (float)gnp.getX(), (float)gnp.getY(), (int)Math.floor(p.getX()), (int)Math.floor(p.getY()), screenPos.x, screenPos.y, evt.getClickCount(), null);
// node.processMouseEvent(gvtevt); processMouseEvent(gvtevt); /* } else if (node == null && evt.getID() == MouseEvent.MOUSE_CLICKED && evt.getClickCount() == 1) { gvtevt = new GraphicsNodeMouseEvent(dummyNode, evt.getID(), evt.getWhen(), evt.getModifiers(), (float)gnp.getX(), (float)gnp.getY(), (int)Math.floor(p.getX()), (int)Math.floor(p.getY()), screenPos.x, screenPos.y, evt.getClickCount(), null);
processMouseEvent(gvtevt); } */
--------------------------------------------------------------------- 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]
