You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Denis Bohm <de...@fireflydesign.com> on 2003/09/04 17:11:13 UTC
Text Selection when events registered?
I have some SVG that includes text elements in a group that has an onclick
event handler. But when I move over the text I get a selection cursor and
can select text. From section 10.16 of the SVG spec it seems like text
selection should not be possible on the text elements because of the onclick
event handler:
"A text selection operation starts when all of the following occur:"
...
"- no links or events have been assigned to the 'text' , 'tspan' or
'textPath' , element(s) (or their ancestors) associated with the given
glyph."
The SVG that I'm using looks similar to this:
<g onclick="dosomething()">
<text>label</text>
</g>
Is this a bug in Batik? Are there any attributes to control if selection is
allowed on individual text elements?
Thanks,
Denis
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Text Selection when events registered?
Posted by Thomas DeWeese <Th...@Kodak.com>.
Denis Bohm wrote:
>>>Denis Bohm wrote:
>>
>>...
>>
>>>>"A text selection operation starts when all of the following occur:"
>>>>...
>>>>"- no links or events have been assigned to the 'text' , 'tspan' or
>>>>'textPath' , element(s) (or their ancestors) associated with the given
>>>>glyph."
>>>
>>> That by the way is a really annoying requirement (they don't even
>>>specify what they mean by 'events' - mutation events? onload events?).
>>
>>I agree. Seems like it would be much better to remove that part of the
>>specification (and just note that the pointer-events attribute can be used
>>to enable/disable text selection).
>
>
> The pointer-events="none" worked great for that specific case where I had a
> rectangle behind the text that then got the event.
>
> I have another case where I have some text that the user can drag around
> (using some onmouse handlers). The pointer-events="none" doesn't work in
> that case - the onmouse handlers aren't called. Is there any way to just
> disable text selection and keep mouse event handlers working?
Not currently (this was under discussion in the SVG WG - should be
easy to add to Batik even as an extension batik:selectable="false").
You could put an invisible rect behind the text:
<rect visibility="hidden" pointer-events="fill" x="..." />
Hack upon hack upon hack .... :)
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Text Selection when events registered?
Posted by Denis Bohm <de...@fireflydesign.com>.
> > Denis Bohm wrote:
> ...
> > > "A text selection operation starts when all of the following occur:"
> > > ...
> > > "- no links or events have been assigned to the 'text' , 'tspan' or
> > > 'textPath' , element(s) (or their ancestors) associated with the given
> > > glyph."
> >
> > That by the way is a really annoying requirement (they don't even
> > specify what they mean by 'events' - mutation events? onload events?).
>
> I agree. Seems like it would be much better to remove that part of the
> specification (and just note that the pointer-events attribute can be used
> to enable/disable text selection).
The pointer-events="none" worked great for that specific case where I had a
rectangle behind the text that then got the event.
I have another case where I have some text that the user can drag around
(using some onmouse handlers). The pointer-events="none" doesn't work in
that case - the onmouse handlers aren't called. Is there any way to just
disable text selection and keep mouse event handlers working?
Denis
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Text Selection when events registered?
Posted by Denis Bohm <de...@fireflydesign.com>.
> Denis Bohm wrote:
...
> > "A text selection operation starts when all of the following occur:"
> > ...
> > "- no links or events have been assigned to the 'text' , 'tspan' or
> > 'textPath' , element(s) (or their ancestors) associated with the given
> > glyph."
>
> That by the way is a really annoying requirement (they don't even
> specify what they mean by 'events' - mutation events? onload events?).
I agree. Seems like it would be much better to remove that part of the
specification (and just note that the pointer-events attribute can be used
to enable/disable text selection).
Thanks,
Denis
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: grab DOM event?
Posted by Thomas DeWeese <Th...@Kodak.com>.
Denis Bohm wrote:
>> 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
>
> The main problem that I have with the transparent rectangle approach is that
> it doesn't cover the case where the user presses within the JSVGCanvas and
> then drags outside. The cursor does not remain set - even though the mouse
> is still captured by the JSVGCanvas. Moves and releases are being processed
> but the cursor does not show the correct feedback.
Ok, it turns out this is more complex than I had thought. During a AWT 'drag'
operation mouse events are always delivered to the element 'under' the cursor.
This is true even when the cursor is outside the window. You have probably not
noticed this because the default value of 'overflow' on the svg element is
'hidden'. If you set this to 'visible' and you use the _very_large_ transparent
rectangle approach you will get all of the behaviour you want! ....
Except! :)
You need to make sure that as the cursor travels over the stuff around your
canvas none of them set the cursor. So for example with squiggle if I move 'quickly'
across the left/right/bottom edges I 'keep' the canvas cursor if I move slowly
across the left/right/bottom edges I get the left/right/bottom edge cursor.
I don't know if this is a problem with squiggle or Java, a few minutes of
searching didn't turn up a reasonable way to overcome this (although I suspect
there is)- any suggestions?
> I tried looking at the
> cursor setting code in Batik to see if I could change the behavior, but it
> seems like it's quite spread out. Any help would be appreciated.
The major piece of work is done in 'BridgeContext' by registering DOM over/out
listeners - it then calls setSVGCursor on the brige.UserAgent that ends up calling
the subclass defined in JSVGComponent that calls 'java.awt.Component.setCursor'.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: grab DOM event?
Posted by Denis Bohm <de...@fireflydesign.com>.
> 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.
The main problem that I have with the transparent rectangle approach is that
it doesn't cover the case where the user presses within the JSVGCanvas and
then drags outside. The cursor does not remain set - even though the mouse
is still captured by the JSVGCanvas. Moves and releases are being processed
but the cursor does not show the correct feedback. I tried looking at the
cursor setting code in Batik to see if I could change the behavior, but it
seems like it's quite spread out. Any help would be appreciated.
Thanks,
Denis
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: grab DOM event?
Posted by Thomas DeWeese <Th...@Kodak.com>.
Denis Bohm wrote:
> 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" <de...@fireflydesign.com>
> To: "Batik Users" <ba...@xml.apache.org>
> 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: batik-users-unsubscribe@xml.apache.org
>>For additional commands, e-mail: batik-users-help@xml.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: grab DOM event?
Posted by Denis Bohm <de...@fireflydesign.com>.
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.
----- Original Message -----
From: "Denis Bohm" <de...@fireflydesign.com>
To: "Batik Users" <ba...@xml.apache.org>
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: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: grab DOM event?
Posted by Denis Bohm <de...@fireflydesign.com>.
> > 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: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: grab DOM event?
Posted by Thomas DeWeese <Th...@Kodak.com>.
Denis Bohm wrote:
>>>2) No mouse events are dispatched when the mouse is moved over areas in
>
> the
>
>>>canvas that don't have any elements drawn. The worst case here is that
>>>mouse releases are lost if done in one of these areas.
>>
>> Sure but this is easily fixed by putting a non-rendered rectangle
>
> behind
>
>>all the content.
>
>
> What happens when the JSVGCanvas isn't the exact same aspect ratio as the
> document? Then the rectangle doesn't cover all of the canvas and the
> problem comes back?
Make the rectangle bigger than the canvas:
<rect x="-500%" y="-500%" width="1000%" height="1000%"
.../>
>>>3) If you press the mouse within the JSVGCanvas, then drag outside the
>>>canvas, then release the mouse - the release is not dispatched.
>>
>>>The last point seems like something that can't be worked around and could
>>>use some handling in JSVGCanvas to pass the release event on - maybe with
>>>the target being the document or root element? The spec doesn't seem to say
>>>anything about this kind of situation, or does it?
>>
>> You should always recieve a mouseout event with a 'null' relatedTarget
>>in this case. I don't think the SVG Specification deals with this
>> directly.
>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: grab DOM event?
Posted by Denis Bohm <de...@fireflydesign.com>.
> > 2) No mouse events are dispatched when the mouse is moved over areas in
the
> > canvas that don't have any elements drawn. The worst case here is that
> > mouse releases are lost if done in one of these areas.
>
> Sure but this is easily fixed by putting a non-rendered rectangle
behind
> all the content.
What happens when the JSVGCanvas isn't the exact same aspect ratio as the
document? Then the rectangle doesn't cover all of the canvas and the
problem comes back?
> > 3) If you press the mouse within the JSVGCanvas, then drag outside the
> > canvas, then release the mouse - the release is not dispatched.
>
> > The last point seems like something that can't be worked around and
could
> > use some handling in JSVGCanvas to pass the release event on - maybe
with
> > the target being the document or root element? The spec doesn't seem to
say
> > anything about this kind of situation, or does it?
>
> You should always recieve a mouseout event with a 'null' relatedTarget
> in this case. I don't think the SVG Specification deals with this
directly.
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?
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: grab DOM event?
Posted by Thomas DeWeese <Th...@Kodak.com>.
Denis Bohm wrote:
>>Denis Bohm wrote:
>>
>>>I'm trying to implement dragging using DOM events. Is there some way to
>>>grab events so that I can make sure I get the corresponding mouse
>
> release
>
>>>(even if the release occurs outside the press element)? Or do I need to
>>>resort to Swing/AWT to do that?
>>
>> This is ussually done using a 'glass pane' - a rectangle that
>>covers the entire canvas and is typically the last element in the
>
> document.
>
>>The rectangle should have 'visibility="hidden"' and initially
>>'pointer-events="none"' - when the user starts dragging you
>>change pointer-events to 'fill' - the rect will then capture all
>>events.
>>
>> You can also leverage the 'capture' phase of DOM events and
>>register your event listener on the root node of the document
>>using EventTarget.addEventListener, with 'true' for the third
>>argument. This allows you to get all events before anyone else
>>normally does. You can then use stopPropagation to stop others
>>from seeing the event (read DOM Events specification for more info).
>
>
> I tried this approach and it seems to have a couple of problems:
> 1) When the mouse is moved over text areas the cursor still changes, even
> though events are captured and not propagated.
Yes, there isn't much you can do about this other than what I suggested
with pointer-events.
> 2) No mouse events are dispatched when the mouse is moved over areas in the
> canvas that don't have any elements drawn. The worst case here is that
> mouse releases are lost if done in one of these areas.
Sure but this is easily fixed by putting a non-rendered rectangle behind
all the content.
> 3) If you press the mouse within the JSVGCanvas, then drag outside the
> canvas, then release the mouse - the release is not dispatched.
> The last point seems like something that can't be worked around and could
> use some handling in JSVGCanvas to pass the release event on - maybe with
> the target being the document or root element? The spec doesn't seem to say
> anything about this kind of situation, or does it?
You should always recieve a mouseout event with a 'null' relatedTarget
in this case. I don't think the SVG Specification deals with this directly.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: grab DOM event?
Posted by Denis Bohm <de...@fireflydesign.com>.
> Denis Bohm wrote:
> > I'm trying to implement dragging using DOM events. Is there some way to
> > grab events so that I can make sure I get the corresponding mouse
release
> > (even if the release occurs outside the press element)? Or do I need to
> > resort to Swing/AWT to do that?
>
> This is ussually done using a 'glass pane' - a rectangle that
> covers the entire canvas and is typically the last element in the
document.
> The rectangle should have 'visibility="hidden"' and initially
> 'pointer-events="none"' - when the user starts dragging you
> change pointer-events to 'fill' - the rect will then capture all
> events.
>
> You can also leverage the 'capture' phase of DOM events and
> register your event listener on the root node of the document
> using EventTarget.addEventListener, with 'true' for the third
> argument. This allows you to get all events before anyone else
> normally does. You can then use stopPropagation to stop others
> from seeing the event (read DOM Events specification for more info).
I tried this approach and it seems to have a couple of problems:
1) When the mouse is moved over text areas the cursor still changes, even
though events are captured and not propagated.
2) No mouse events are dispatched when the mouse is moved over areas in the
canvas that don't have any elements drawn. The worst case here is that
mouse releases are lost if done in one of these areas.
3) If you press the mouse within the JSVGCanvas, then drag outside the
canvas, then release the mouse - the release is not dispatched.
The last point seems like something that can't be worked around and could
use some handling in JSVGCanvas to pass the release event on - maybe with
the target being the document or root element? The spec doesn't seem to say
anything about this kind of situation, or does it?
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: grab DOM event?
Posted by Thomas DeWeese <Th...@Kodak.com>.
Denis Bohm wrote:
> I'm trying to implement dragging using DOM events. Is there some way to
> grab events so that I can make sure I get the corresponding mouse release
> (even if the release occurs outside the press element)? Or do I need to
> resort to Swing/AWT to do that?
This is ussually done using a 'glass pane' - a rectangle that
covers the entire canvas and is typically the last element in the document.
The rectangle should have 'visibility="hidden"' and initially
'pointer-events="none"' - when the user starts dragging you
change pointer-events to 'fill' - the rect will then capture all
events.
You can also leverage the 'capture' phase of DOM events and
register your event listener on the root node of the document
using EventTarget.addEventListener, with 'true' for the third
argument. This allows you to get all events before anyone else
normally does. You can then use stopPropagation to stop others
from seeing the event (read DOM Events specification for more info).
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
grab DOM event?
Posted by Denis Bohm <de...@fireflydesign.com>.
I'm trying to implement dragging using DOM events. Is there some way to
grab events so that I can make sure I get the corresponding mouse release
(even if the release occurs outside the press element)? Or do I need to
resort to Swing/AWT to do that?
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: Text Selection when events registered?
Posted by Thomas DeWeese <Th...@Kodak.com>.
Denis Bohm wrote:
> I have some SVG that includes text elements in a group that has an onclick
> event handler. But when I move over the text I get a selection cursor and
> can select text. From section 10.16 of the SVG spec it seems like text
> selection should not be possible on the text elements because of the onclick
> event handler:
>
> "A text selection operation starts when all of the following occur:"
> ...
> "- no links or events have been assigned to the 'text' , 'tspan' or
> 'textPath' , element(s) (or their ancestors) associated with the given
> glyph."
That by the way is a really annoying requirement (they don't even
specify what they mean by 'events' - mutation events? onload events?).
> The SVG that I'm using looks similar to this:
>
> <g onclick="dosomething()">
> <text>label</text>
> </g>
>
> Is this a bug in Batik?
Apparently :)
> Are there any attributes to control if selection is
> allowed on individual text elements?
pointer-events="none"
>
> Thanks,
> Denis
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org