OK, here is what I have done: - Registered the EventListener to the root element (SVGDocument.getDocumentElement()). - I have a background rect element because I want the user to be able to set the background. I don't have any listeners registered to this rect; it's just there and filled with a color. - I transform the coordinates in my MouseMove event by getting the client X/Y from the DOMMouseEvent, creating an SVGOMPoint, and inverting the matrix from the event.getTarget().getScreenCTM(). - Append deltas between MouseMoves to the target element's transform.
This sounds like one of your solutions. The mouse seems to eventually "lead" the element, but it seems like the event listener is still being fired. If I click in the middle of an element and start dragging it to the right, for example, eventually the mouse will be farther right than the element. The element continues to move. I'm not sure where/why the element is losing ground that the mouse is covering. I've implemented your background solution; is there any advantage to using a glass pane rect instead? It's mostly usable; just after prolonged dragging, it gets really off the mark. Michael Bishop -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 26, 2005 9:54 PM To: [email protected] Cc: [email protected] Subject: RE: Weird problem using translations. Hi Michael, "Bishop, Michael W. CONTR J9C880" <[EMAIL PROTECTED]> wrote on 10/26/2005 03:08:03 PM: > c.) You can apply a transform on your selected element. To do so you need to > perform a matrix transform from previous transforms this object has had. For > example, the first time you drag an object, you will add a transform attribute > such as: transform="translate(dragpt.x, dragpt.y)", but for subsequent drag > operations you need to do, for each axis: oldtransformCoordinate + newCordinate > > Assuming that I?ve already placed a ?transform? attribute on every element I > create, the initial transform doesn?t hold true. However, you can?t simply > append oldTransformCoordinate + newCoordinate; rather you need to add the > delta between MouseMove events. Correct the important thing is to map the mouse moves into the 'target' coordinate system. The easiest way to do this is by using the getScreenCTM method with the 'clientX/Y' field of the Event. Don't use AWT event listeners use the DOM event listeners. > This is the solution I?m unsuccessfully pursuing. Is there a desktop solution? > The Adobe SVG viewer is mostly JavaScript. Can the JSVGCanvas handle changing > the transform on an object for every MouseMove events? It depends a bit on how complex the document is but generally yes. > Does an example exist? You can take a look at samples/solitaire/towers.svg For moves I generally map the start 'clientX/Y' to the group that I will be moving the element in. Then I can calculate deltas as the mouse moves and add them to the base 'transform'. > I?ve read that transforms are pretty costly operations. If it can?t be > done, I may need to use a 2D shape on the glass pane and only change the > element when the mouse is released; resulting in one element change > instead of having the document render every time I move the mouse. This will be quicker as it won't have to re-render the modified portions of the document on every mouse move but from what I know of what you are doing I have a hard time believing that you will have significant performance problems. > OK, I have more of an idea as to what?s going on; it seems that > MouseMotionListeners are more ?precise? than EventListeners. I capture the > ?delta? between the ?current? MouseEvent coordinates and the ?previous? > MouseEvent coordinates. The mouse seems to move further than the DOM > EventListener registers. The MouseMotionListener keeps up just fine: The DOM mouse moves are 'compressed' so if multiple mouse moves come in before the first can be dispatched to the DOM tree they will be compressed into one mouse move. This way if event processing bogs down they event's don't "back up". I'm sure AWT does the same thing with the lower level OS mouse move events. Another common problem is that if the mouse moves 'to quickly' it will fall off the current element and your DOM event listener may not be called. This is why it's useful to either use a glass-pane (a fully transparent, often I use one with visibility="hidden" pointer-events="fill", rect that sits over the entire document). You can get a similar effect by having a background rect and registering your listener on the root SVG element (and just use 'target' instead of 'currentTarget'). > Are there any examples out there that use transformations to achieve > drag and drop? The solitaire examples do (they are a little complex however). > I had better success setting the coordinates of the element > directly, but as Thomas pointed out it?s more work. For a rectangle, it?s > X/Y. For an ellipse, it?s CX/CY. For a line it?s TWO points and for a > polyline it?s ?n? points. I?d rather use transformations, but I?m running out > of troubleshooting ideas. > > Michael Bishop > > > From: Bishop, Michael W. CONTR J9C880 [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 25, 2005 4:57 PM > To: [email protected] > Subject: Weird problem using translations. > > I sure hope I can describe this one without pictures. I?ve started to use the > ?translate? attribute to move elements around the JSVGCanvas. I have a > DragStatus object that keeps track of what I?m dragging. Here is what my codeis doing: > > MouseDown: > Set DragStatus.dragStatus to DRAG_DOWN. > Capture the Element I pressed the mouse on and save it as the DragStatus. > selectedElement. > Capture the coordinates of where the mouse was pressed and save it as the > DragStatus.dragDownPoint. > > MouseMove: > Capture the current DOMMouseEvent coordinates as an SVGOMPoint and > convert from screen coordinates. > Run a MoveRunnable Runnable in the UpdateManager, sending the > SVGOMPoint and the DragStatus.selectedElement. > > MoveRunnable(Element element, SVGOMPoint location): > Create an instance of WhiteboardElement(element) which is what I > use to ?wrap? elements. Subclasses (RectangleElement, EllipseElement, etc.) > know how to generate color information, transforms, etc. for the wrapped Element. > > Set the new ?translate? piece of the ?transform? attribute as follows: > > // Set the ?new? translation coordinates as [current element translate > coordinates] + [current mouse coordinates] ? [mouse coordinates of mouse press]. > float translateX = (whiteboardElement.getTranslateX().floatValue() + location. > getX() ? DragStatus.getDragDownPoint().getX()); > float translateY = (whiteboardElement.getTranslateY().floatValue() + location. > getY() ? DragStatus.getDragDownPoint().getY()); > > // Set class variables for X and Y translations. > whiteboardElement.setTranslateX(new Double(translateX)); > whiteboardElement.setTranslateY(new Double(translateY)); > > // Set the ?transform? attribute of the actual Element (triggering the change > to the document I think. > whiteboardElement.addTransform(); > > All of this ?sort of? works. With slow mouse moving, you get kind of jerky > motion across the canvas. Any sudden mouse movements cause the element to > ?fly off? the canvas on its own. It?s especially apparent with lines and > polylines. I *think* the trigger is moving the mouse far enough to register a > ?mouse moved? event when the mouse is ?off? the element you?re dragging. > > Any suggestions? Smoother motion would be nice; the element seems to ?wobble? > when you move it, but stopping it from flying off the canvas entirely would be > very helpful. I?ve been pulling my hair out for the better part of the afternoon?J > > Michael Bishop --------------------------------------------------------------------- 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]
