Abstract: Advanced Mouse Event Model for SVG

Musbah Sagar (msagar@brookes.ac.uk)
Chris Cooper (cscooper@brookes.ac.uk)
David Duce (daduce@brookes.ac.uk)

In this paper we will present our work on a new mouse event model built on top of the DOM Level 2 Event Model [1] written in JavaScript for SVG. The work is concerned with defining a higher level of abstraction particularly for handling mouse events. The work described in this paper is believed to ease the process of developing SVG applications in the future (i.e. GUI components) and may perhaps inspire changes to the current SVG mouse event model to make it easier to develop interactive applications for SVG.

The paper will shed the light on the notorious "out of synchronous mouse state" problem commonly known in the SVG environment. Applications written for SVG suffer the long known problem of losing the mouse attention once the mouse pointer leaves the painted area of the SVG element - where a particular mouse event is being listened to (captured) - or goes completely out of the SVG canvas. There are many similarities between the current state of the mouse event model of SVG and that of C++ applications written for the Windows operating system; this paper/abstract will address this issue.

The work described in this paper relays fundamentally on previous work at Oxford Brookes University called svgDraw2D. svgDraw2D was used previously for the implementation of the SVG Browser for XML Languages[2]. The svgDraw2D package is written for SVG in JavaScript to decouple the manipulation of DOM/SVG interfaces from writing graphics applications. The package provides a higher level of abstraction to JavaScript developers to manipulate graphics independently from the DOM API (knowledge of SVG and DOM is unnecessary). It also provides capabilities for drawing sophisticated two-dimensional shapes, working with fonts, text and text layout, controlling colours; and it features layering management, styled tooltips and desktop canvas. A brief description of this package will be given in the paper.

So, what is wrong with the current DOM level 2 event model? And why it is not good enough for developing SVG applications? Well, let's consider this hypothetical scenario. Imagine that a user wants to drag the scrollbar of a TextList widget written for SVG. The user clicks the mouse button on the scrollbar moving box and starts dragging it. But before the mouse button is released the mouse pointer - accidentally - goes out of the boundary of the scrollbar (the reason can be a slow machine or intensive drawing) and the user looses the mouse focus (mouse events stop being delivered to the scrollbar mouse events handler function). The user releases the mouse button while the mouse pointer is out of the scrollbar boundary and then moves the mouse pointer back to be inside the scrollbar region. Because the mouse events handler of the scrollbar stops receiving mouse events once the mouse pointer is out of its boundary (or if the mouse events are being captured on the background it will stop receiving mouse events once the mouse pointer is out of the SVG canvas), the mouse state of the widget becomes out of synch with the real mouse state and that could cause all kinds of confusion.

This paper will not describe the different ways of solving this/and other mouse events handling problems, instead it will present a comprehensive solution to them and a powerful mouse event handling model that will make developing interactive applications for SVG an easy/normal exercise.

It is interesting how an old problem which has been solved and long forgotten in one domain appears in another!. Not long time ago, C++ developers used MFC to write windows applications. In C++, mouse messages (events) are sent to the currently active window to be processed and acted upon. BUTTONUP, BUTTONDOWN (for the left, middle and the right mouse buttons) and MOUSEMOVE are the only sorts of mouse events generated by windows for its applications. Those mouse events are only delivered to the application so long as the mouse cursor is on the client's region (painted area). Sounds familiar?

To receive the mouse events outside the application window one has to do what is known as capture the mouse first. This concept is familiar to those who program in C++ for Windows. Two methods which are used to achieve this effect are CWnd::SetCapture and CWnd::ReleaseCapture. Once the mouse is captured, windows operating system will send all mouse events to the application all the time (mouse within or out of the application window). A good time to start the mouse capture process is when the user clicks on the application window, this will ensure that the application will certainly receive the MOUSEUP message whether the mouse pointer was in or out of the application window boundary.

In a Java environment, the process of handling mouse events was made easy for Java developers by introducing a wider set of mouse events (mousePressed, mouseReleased, mouseEntered, mouseExited, mouseCliced, mouseMoved and most importantly mouseDragged). All Java mouse events are generated from windows simple mouse messages described above. Java hides the complexity of having to capture the mouse messages once the mouse is out of the application window (to generate the mouseDragged event) from Java users. This extra layer of abstraction in handling mouse events has its great advantages in making the development of Java applications less painful than that of C++.

For all the above reasons, we had decided to adapt Java mouse model as the basis for our design and implementation. Our model is able to process row low-level SVG/DOM mouse events to produces Java AWT-like events. The paper will explain how the new mouse events can be captured using mouse events and mouse motion listeners' interfaces on all graphic objects (part of svgDraw2D). We will show how to prepare JavaScript objects of type Graphic to enable mouse events (mousePressed, mouseReleased, mouseEntered and mouseExited) and mouse motion events (mouseMoved, mouseStartDragged*, mouseEndDragged*, mouseDragged) for processing and handling. The example application provided with the paper will emphasise the ability of the new mouse event model to capture all the above mouse events without the out of synch problem explained earlier even when the mouse pointer moves out of the SVG canvas (goes out of the browser/viewer's window).The work also features an implementation of a few GUI components implemented on top of the new mouse event model.

A full description of the design and implementation of the mouse event model is provided in the paper. The new mouse event model was successfully used in the process of porting JHotdraw[3] to SVG. The work on JHotdraw is being carried out as part of our research on the Web-Enabled Collaborative Workspace Environment at Oxford Brookes University under the Open Overlays project [4]. This work was tested successfully on Adobe SVG plug-in and Apache Batik SVG viewer and the results were amazingly realistic.


[1] Document Object Model (DOM) Level 2 Events Specification: http://www.w3.org/TR/2000/REC-DOM-Level-2-Events-20001113/
[2] M.S. Sagar, "An SVG Browser for XML Languages", Proceedings of the Eurographics UK Chapter Conference, Birmingham, June 3-5, 2003. Published by IEEE Computer Science Press.
[3] Java Graphical Editing Framework (JHotDraw): http://www.jhotdraw.org/
[4] Open Overlays Project: http://www.comp.lancs.ac.uk/computing/research/mpg/projects/openoverlays/

*: Not supported in Java

Valid XHTML 1.1!