lib-gwt-svg 0.5.6 brings several additional features, such as support for SVG drag-and-drop and CSS/SVG backgrounds. lib-gwt-file 0.3.1 brings a working implementation of Blob.slice and support for large files (up to 2^56 bytes long). svgreal 0.2.2 provides support for image element [...]]]> I am releasing today a new version of most my GWT libs, apps and games.

lib-gwt-svg 0.5.6 brings several additional features, such as support for SVG drag-and-drop and CSS/SVG backgrounds.
lib-gwt-file 0.3.1 brings a working implementation of Blob.slice and support for large files (up to 2^56 bytes long).
svgreal 0.2.2 provides support for image element edition (with drag-and-drop support) and use element edition.

Most of the games, samples and demos have been reworked to take into account a recent evolution in Firefox SVG engine which caused the apps to not function properly on Firefox any more (see https://bugzilla.mozilla.org/show_bug.cgi?id=752583 for details).

To achieve that I decided to make the following changes:

What is supported exactly [...]]]> Several developers have been asking whether SVG supports html5 drag-and-drop. Until now, I usually answered: “no way, the SVG specification predates the HTML5 specification and does not mention drag-and-drop, so there is no chance that will work”. The goods news is that things are starting to evolve in several major browsers.

What is supported exactly ? At the moment, only Firefox and Chromium seem to implement SVG drag-and-drop. Both implementations are not fully working yet, though Firefox seems closer to the goal that Chromium. Both implementations have a problem with SVG drag sources (see: https://bugzilla.mozilla.org/show_bug.cgi?id=691796), bug drop works well, even on arbitrary elements inside an svg element. Chromium does not seem to support drag images.

I have uploaded a new development snapshot of lib-gwt-svg on the new githhub repository which includes this feature. There is also a new sample demonstrating the feature, available on github also: https://github.com/laaglu/lib-gwt-svg-samples.

Adding this feature caused quite a change in the way I implement event handling. When I first created the library, I was confronted with the need to add support for SVG-specific DOM events to the GWT stack. Since the GWT is not designed to allow adding custom DOM events, I had to re-create my own classes to process all SVG DOM events. I did that the conservative way, using a design largely inspired by GWT itself: every DOM element has a custom integer bit mask used to keep track of the kinds of event sunk by that element ; event handlers are set-up by converting the event name to an integer mask, checking the proper bit value associated with the mask and setting the on<eventname> property associated with that event. It turns out a drag and drop adds seven new events to the list, which brought that total number of supported events to 34, greater than 32 bits of a java integer. After some head-scratching, I have decided to go my own way and use something much simpler: no more event masks, no more bitfields, etc… Maybe at a point in time they were required to make it work, but this is no longer the case. Modern browsers with SVG support all support addEventListener and removeEventListener; thus, since registering and event handler always starts with the event name anyway, why not use these functions instead ? I have updated all my applications and have not detected any regression so far. Before committing to a release build, I would like to have feedback from other users.

Another interesting side effect of the change is that I changed the code to actually remove the DOM event listener when an element no longer has any handlers listening to a particular event anymore. This is done with a specially modified kind of EventBus. Before that, it was not the case. Removing an event handler left the DOM event listener connected. This event listener kept firing events in the void, since there was not anybody connected any more at the other end of the event bus.

One more thing: since not all browsers support SVG drag-and-drop events, I was again confronted with the need to provide a run-time function applications can check to determine if support is present or not. A pattern began to form (I had just done that for touch events), and I thought that SVG natively has a means to check that features are available. Why not reuse that instead of adding extra functions to the API ? Therefore, there are two new constants defined in SVGConstants.

The proper way to check for feature availability is to call:

The method DOMHelper.supportsSvgDndEvents is deprecated (it will become private in an upcoming release and be invoked from DOMHelper.hasFeature).

If you ran a previous version of svgreal, make sure you click Shift [...]]]> I am releasing a bug-fix release of to address the following bug which sort of ruined the whole editing experience of the app:

• manipulators are not displayed at the proper location if the ancestors of the element to edit have transforms.

If you ran a previous version of svgreal, make sure you click Shift + Reload button in your browser, to force your browser to bypass its cache and reload the new version of the program.

I am also adding a new URL (http://www.vectomatic.org/gwt/svgreal-latest/svgreal.html?demo=013) for people who want to bookmark the app and be updated automatically to the latest level. Alternatively, you can also bookmark a particular version of the app to remain pegged at this particular version.

There are now five main sections:

With regards to touch event support, here are the main points you [...]]]> I am launching today lib-gwt-svg 0.5.5. The main highlight of this release is support for touch events. This version also fixes a few bugs and adds minor features I needed for my new project svgreal. The specifics is detailed in the release notes.

With regards to touch event support, here are the main points you should be aware of.

The SVG specification does not officially support touch events in any form (it predates touch events). However a few browser have added touch events to SVG elements, using the following heuristic: anything which supports mouse events also supports touch events. I have taken this approach too and added the four handler registration methods to the these elements: OMSVGAElement, OMSVGAnimationElement, OMSVGCircleElement, OMSVGDefsElement, OMSVGEllipseElement, OMSVGForeignObjectElement, OMSVGGElement, OMSVGImageElement, OMSVGLineElement, OMSVGPathElement, OMSVGPolygonElement, OMSVGPolylineElement, OMSVGRectElement, OMSVGSVGElement, OMSVGSwitchElement, OMSVGSymbolElement, OMSVGTextContentElement, OMSVGUseElement

Adding support for handler registration does not mean that the underlying browser actually supports and fires them. Also keep in mind that a device may support touch events for HTML elements, but not for SVG elements. To test if SVG touch events are supported, I provide a runtime method in the class DOMHelper

Tests made so far indicate the following:

I have not tested on iOS devices yet, neither on the new Chrome Android browser. Any information of users on these platforms are welcome !

With regards to gesture events, I have decided to take a cautious approach as they do not seem to gain a lot of traction beyond the iOS world. Low-level support has been added in DOMHelperImpl, but I have not added handler registration method to the APIs. If they get normalized and adopted, I will of course reconsider.

I do not provide a sample for touch events yet. I plan to create a few demos for the next version of lib-gwt-svg.

The (long term !) purpose of project svgreal is to let anyone with a browser open and edit any SVG resource locally or on the Internet. Real svg resources, not just svg resources originally created by svgreal itself. Users should be able to open multiple [...]]]> I am launching todayan online app to edit SVG resources.

The (long term !) purpose of project svgreal is to let anyone with a browser open and edit any SVG resource locally or on the Internet. Real svg resources, not just svg resources originally created by svgreal itself. Users should be able to open multiple svg images, copy cut and paste interesting bits of them, edit existing elements and author new ones, and push the resulting new image anywhere locally or on the internet.

As anyone who knows SVG will tell, the goal is very ambitious: the SVG specification is very large, and connects with several other equally vast standards (CSS, SMIL, javascript events), which require support to at least a certain degree. The first snapshot published today is the result of one year of development efforts, so you can make your own guess as to how long the project is going to take before it matures into something truly useful. Of course contributions to the project from other people could alter this roadmap.

What do I have today ?

• A multiple document interface, based on GXT, which lets one open several SVG documents, coming from your filesystem, an URL or the openclipart project.
• Navigation in SVG documents, where one can see the structure of the documents, highlight elements, rotate and zoom you view, change the viewbox of the document
• Create and edit basic elements: lines, circles, ellipses, polygon, polylines, path, images, using either mouse based graphical manipulators, or precise numerical coordinates in a property sheet.
• Edit element transforms.
• Re-order elements, drag and drop them between documents
• Edit graphical attributes of existing elements (line thickness, paint, dash arrays, …)
• Undo / redo
• Export back to SVG

These features have only tested them on a limited set of SVGs (ie: the app is very likely to crash or not be stable with other SVGs). To reach industrial strength quality, a lot of polishing of the existing features is going to be required as well as unit tests to guarantee non-regression on these patches.

What are the missing features I am beginning to work on in 2012 ?

• Number one priority: stability, bug fixing, broaden the usability of the program and number of platforms supported.
• Missing graphical elements: use, text
• Support for gradients and patterns
• Scripting and automation
• Support for saving to various locations (local storage, cloud, http WebDAV)
• Port to GXT3.x
• Support for missing graphical properties (such as preserveAspectRatio)

What are the other missing features

• Support for animation
• Support for styles defined in external CSS documents
• SVG filters
• Clipping, masks, text on paths…
• Import or Export from other formats
• Nested SVG elements, switch, …
• Fonts
• Advanced drawing tools

As GWT 2.4.0 now provides native support for HTML 5 drag-and-drop, lib-gwt-file 0.2 uses these native event classes instead of its own, wherever possible. lib-gwt-file’s own drag-and-drop [...]]]> lib-gwt-file 0.2 is now available. It does not provide new functionality with regards to the previous release, but is a migration to GWT 2.4.0.

Changes in this release

As GWT 2.4.0 now provides native support for HTML 5 drag-and-drop, lib-gwt-file 0.2 uses these native event classes instead of its own, wherever possible. lib-gwt-file’s own drag-and-drop event classes are deprecated and will be removed in the next release of the library. Please see the release notes for the list of classes being deprecated.

Migration guide

To migrate to lib-gwt-file 0.2, replace the imports to all lib-gwt-file event classes related to drag-and-drop and replace them with GWT 2.4.0 equivent classes. This is fairly easy as all classes have the same name (you only need to change the package). There is one exception to this rule. GWT 2.4.0 DataTransfer class does not expose any file-related APIs, as GWT 2.4.0 does not yet support the W3C file API. I have thus provided an extended overlay class wrapper, DataTransferExt, which adds the missing functionality. Thus, to use it, replace code like this:

with:

lib-gwt-file-test sample

The lib-gwt-file-test has been migrated to the new API. Support has been added for PNG files, in order to demonstrate the readAsBinaryString method. However users should be aware that further changes in this area are very likely, as September 2011 W3C draft proposes new changes to the specification.