|
|
I am releasing a lot of new code and projects today, so I have decided to take advantage of this opportunity to restructure the vectomatic website.
There are now five main sections:
- 1. apps
- Contains online web apps, the most notable one being the new svgreal SVG editor.
- 2. libs
- Contains lib-gwt-svg and lib-gwt-file.
- 3. games
- Contains my chess and educational games.
- 4. utils
- Contains only a slider component at the moment. I plan to release various tools of my own here in 2012.
- 5. posts
- Contains the blogging part of this site.
Notable highlight of today’s release include:
 , an advanced SVG editor (be sure to check it out !)- a new version 0.5.5 of lib-gwt-svg.
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
public HandlerRegistration addTouchCancelHandler(TouchCancelHandler handler)
public HandlerRegistration addTouchEndHandler(TouchEndHandler handler)
public HandlerRegistration addTouchMoveHandler(TouchMoveHandler handler)
public HandlerRegistration addTouchStartHandler(TouchStartHandler handler) 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
public static boolean supportsSvgTouchEvents() Tests made so far indicate the following:
| Browser |
Support |
| Firefox mobile 9.x |
Ok, but only supports single touch events. True multitouch is planned for 11.x |
| Playbook browser |
Ok (thanks to Michael Baranov for the tests and support in the implementation) |
| Android stock browser |
Not working |
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.
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
I am releasing today a new version of lib-gwt-file, to try to keep up with the specification and recent evolution in the W3C draft specification. The highlight of this new version are as follows:
-
Migration of the interfaces to the lastest W3C file API draft (W3C Working Draft 20 October 2011), except for error management which still relies on FileError (as the new error management classes do not seem to be implemented by webkit or FF yet)
- Addition of javadoc for most of the existing methods (the doc is a mix from MDN documentation, extracts from the spec and my own comments).
- Support for typed arrays from the lastest Khronos Group specification (Editor’s Draft 19 October 2011)
-
Fixed bug in DropPanel (incorrect firing of dragenter and dragleave if the DropPanel contains nested elements)
I have also upgraded my sample program significantly, with a focus on two areas:
- Error management, which cannot be written in a totally cross-platform way yet, as FF needs to be treaded as a special case (see https://bugzilla.mozilla.org/show_bug.cgi?id=701154). Expect more changes in this area as the spec has evolved a lot in this area, though browsers have not implemented it yet (and neither have I).
- Memory management: it seems it is a bad idea to create a new FileReader for every file being read, as this create memory leaks. The sample using a queue base approach and reuses the same reader.
You can find all the details about the new version in the release notes.
The sample is available here
I am releasing a new version of lib-gwt-svg. For a detailed list of changes, see the release notes. This new version is mostly a bug-fix and tuning release, which provides better support for IE9 and Opera. Among the notable features of the release are:
- On IE9, the XPath APIs are now supported. This is made possible by embedding the xpath.js library by Cameron McCormack, which provides the XPath support lacking in IE9 and IE10. Other browsers, which have native xpath support are unchanged and do embed xpath.js.
- On IE9, stylesheets embedded in dynamically loaded SVGs are not ignored any more (found a workaround for this IE9 bug)
- On Opera, xlink hrefs embedded stylesheets contained in dynamically loaded SVGs are not broken any more (found a workaround for this Opera bug)
- On all platforms, OMSVGParser.parse will throw a ParserException in a consistent manner when fed input which is not well-formed or is not an SVG document
I have created a new XPath sample in the lib-gwt-svg-samples program. It lets you type xpath expressions which are evaluated on the fly, resulting in the proper nodes being selected in the SVG and XML view of a sample document.
I have updated all my educational games to use the latest version. The following matrix shows what works and what does not, per platform:
|
FF |
Webkit (chrome) |
Opera |
IE |
| samples-shapes |
 |
|
|
|
sample-events |
|
|
|
|
sample-parser |
|
|
|
|
sample-widgets |
|
|
|
|
sample-xpath |
|
|
|
|
sample-smil |
|
 (No JS SMIL support)
| |
(No SMIL support) |
games-chess |
|
|
|
|
games-dots |
|
(No JS filter support)
| |
(No filter support. Coming in IE10) |
games-maze |
|
|
|
|
games-push |
|
|
|
|
games-puzzle |
|
|
|
|
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:
FileList files = event.getDataTransfer().getFiles(); with:
FileList files = event.getDataTransfer().<DataTransferExt>cast().getFiles()); 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.
Hi,
Concomitantly to the release of GWT 2.4, I am releasing a new version of lib-gwt-svg (0.5.3). For a detailed list of changes, see the release notes. This new version, besides providing compatibility with GWT 2.4, provides improvements in two areas:
It supports SVG paint (colors, named colors, gradients, patterns) and dash-arrays by providing parsers for these data types. A dedicated post details these new capabilities.
It incorporates a patch proposed by Michael Allan of zelea.com to let lib-gwt-svg support subclassing or wrapper types. You can now write constructs like:
public class MyCircle extends OMSVGCircleElement {
}
MyCircle c = new MyCircle();
OMSVGSVGElement svg = new OMSVGSVGElement();
svg.appendChild(c); I am also releasing a new version of lib-gwt-svg-chess, which is based on the latest version (0.6) of the carballo chess engine. Alberto Alonso Ruibal, the author of this engine, has modified it to make it compatible with GWT. Thus, as of this release, I will no longer maintain and distribute my own GWT version of it (carballo-gwt) and use the official version directly.
In parallel, the IE9 compatibility picture continues to improve: my chess game now runs in IE9+, and three out of four of my educational games run in IE9+ (dots is still not working). The only two remaining hurdles are lack of SVG animation and lack of XPath support in IE9+.
The SVG standard provides a complete API to deal with various forms of paint (rgb colors, named colors, linear gradients, patterns, …) and this API integrates tightly with the CSS APIs to provide programmatic access to the various characteristics of the paint. The dash-array CSS property can also be introspected with the same CSS APIs.
In real web development however, things are not as easy as they should, because almost all browsers fail to implement correctly if at all at least some part of the specification. This is why I had not tried to incorporate this part of the specification in lib-gwt-svg so far.
If things were perfect, all one would have to write to access a color or the dash-array attribute would be:
<svg xmlns="http://www.w3.org/2000/svg">
<circle id="c1" style="fill:tomato;stroke:black;stroke-dasharray:2mm,1mm" cx="10" cy="10" r="5"/>
</svg> var circle = document.getElementById('c1');
var paint = circle.style.getCSSPropertyValue('fill');
var green = paint.rgbColor.green;
var greenValue = green.getFloatValue(green.primitiveType);
var dash1 = circle.style.getCSSPropertyValue('dash-array').item(0);
var dash1Value = dash1.getFloatValue(dash1.primitiveType); In the real world, the code above does not run well in most browsers:
| Browser |
Result |
| Firefox 4+ |
getCSSPropertyValue works only for computedStyle, not style |
| Chrome 14+ |
Works correctly |
| Opera 10+ |
Not supported (exception thrown) |
| IE9+ |
Not tested |
In version 0.5.3 of lib-gwt-svg, I have developed a few classes to emulate most of the behavior of SVGPaint and CSSValue and map it to GWT. The implementation is based on parsing the css text value of the css properties to create a small graph of objects representing the color. The shortcoming of this approach is that this graph is an emulation: changing it will not affect the original CSS property. With this restriction in mind, it is now possible however to write applications which manipulate SVG paint and dash arrays, in a portable way. If browser implementations make enough progress, I plan to switch to the native implementation.
Here is sample code which uses it:
OMSVGCircleElement circle = (OMSVGCircleElement)OMSVGParser.currentDocument().getElementById("c1");
OMSVGPaint paint = (OMSVGPaint)circle.getStyle().getSVGPropertyCSS(SVGConstants.CSS_FILL_PROPERTY);
OMRGBColor green = paint.getRgbColor().getGreen();
float greenValue = green.getFloatValue(green.getPrimitiveType());
OMCSSValueList dashArray = (OMCSSValueList)circle.getStyle().getSVGPropertyCSS(SVGConstants.CSS_STROKE_DASH_ARRAY_PROPERTY);
OMCSSPrimitiveValue dash1 = (OMCSSPrimitiveValue)dashArray.getItem(0);
float dash1Value = dash1.getFloatValue(dash1.getPrimitiveType()); To conclude this post, here is a pointer to the javadoc documentation of this API.
With the release of GWT 2.3.0, IE9 is now part of the browsers officially supported by GWT. Since IE9 has SVG support, I have updated lib-gwt-svg to take advantage of it. The samples have been migrated and most of them work, except for the usual SMIL animation which is not supported by IE9.
Actually the port did not require a lot of work once GWT 2.3.0 was available. I have changed the way lib-gwt-svg integrates with UiBinder, because this integration was based on XPaths and it turns out IE9 does not support XPath (neither does the current IE10), so be carefull if you rely on the DOMHelper XPath methods for your app.
There are certainly still problems with lib-gwt-svg IE9 support. I have not been able to get my other, more advanced apps to run correctly (no chess, no educational games). I need to do some more debugging to figure out why (problems on my side or IE9 bugs). However, since the samples work now correctly, I considered this to be a worthy milestone and thought I would release it. Anyhow, support for GWT 2.3.0 was needed anyway.
Beyond IE9 support, there are a few extra goodies, such as an API to fetch external XML resources using IFrames and XmlHttpRequests, see the release notes for details.
This post presents lib-gwt-file, a library which encapsulates the W3C File API and the HTML5 drag-and-drop interfaces.
Let me begin by explaining why I developed this library and how I expect it to evolve. I am currently developing an SVG editor based on GWT and lib-gwt-svg and to be truly useful, users need to be able to update the drawings they have on their own computer. I came across a mozilla article presenting the file API support they have built into FF3.6 and FF4. This was exactly what I needed, except I needed it in GWT form. I read the specs (W3C file API and HTML drag-and-drop) and implemented what I needed to cover my needs. It then appeared to me that other developers would probably have this need too and that it would be mutually beneficial to share this code.
I do not expect this library to live a very long life. The specifications are still in draft stage, but the GWT team will probably implement it in a not too distant future (2012 ?) as the feature is general enough and important enough to make it into GWT; they are probably waiting for the spec to mature a bit and the other browser vendors (opera, microsoft) to implement it. Until they do, you can rely on lib-gwt-file to implement your local file open functionality. Migration to the official GWT API once it exists should not be too difficult.
At the moment the lib is not very well documented or tested (version 0.1), but I am using it and it works for me. You can look at the project page for details. There is a sample with code source available. It runs in FF4 and Chromium. Note that the code is compatible with GWT UiBinder: it declares new event classes and you can use the standard UiBinder event hookup facility to automatically register for these events (this is what the sample does).
documented
|
