|
|
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
This post summarizes changes and new features to vectomatic and lib-gwt-svg.
lib-gwt-svg
A new version 0.5.1 is introduced, to provide formal support for GWT2.2.0. It is mainly a bug-fix and improvement release, but it contains a large number of fixes (see the release notes for details). It is available through the usual channels: maven central repository, vectomatic website, and google-code project.
lib-gwt-svg-samples
The samples for lib-gwt-svg have been revamped too (version 0.5.2) to finish the work started on CSS and SMIL animation. The SMIL animation sample now works as expected (on FF4 and Opera). The widgets sample layout has been redesigned to demonstrate scalability of widgets.
lib-gwt-svg-edu
Additional new GWT projects have been created to make the games available as Opera Widgets and KDE Plasmoids. The Opera Widgets are already functional, the KDE plasmoids not yet. More work is still required though on the CSS front to make the game appearance and responsiveness adequate for use on mobile devices. Thus the widgets are not yet published on the Opera repository.
Repository structure
The unified SVN repository structure which contains all vectomatic projects is going to be split in several parts. The reason is that it is becoming difficult to synchronize the release of all these projects into one big meta-release and that they will evolve better if they can have a lifecycle of their own. The plan is to have at least three repositories:
The vectomatic2 development has already been extracted to a private svn repository and is receiving intensive care. A new project (with a new name) will be created and announced shortly to host it.
A first (small) step has been made on the way towards running lib-gwt-svg apps into IE9. I have done some tests with the latest code available (called “platform preview 7″). The good news first: a few of the tabs in lib-gwt-svg-samples work, with the present unmodified code (version 0.5.0): shapes, events, features. This is encouraging because it means you can create SVG shapes and receive events. The bad news now: all the other apps are not working (yet).
How do I interpret these results ? It seems IE9 is a two headed beast, and these two heads do not talk to each other at all. Either you choose the new IE9 mode, by putting the HTML5 doctype header in your document; or you choose the compatibility mode.
In IE9 mode, you must do everything by the standards (CSS layout, HTML5, W3C DOM APIs). If you deviate a tiny bit or try to use the old IE way, it won’t work, contrary to other browsers which know how to handle legacy and degrade more gracefully.
In compatibility mode, you basically have that outdated and full of quirks and bugs browser, which knows nothing of the new features but has good compatibility with legacy MS apps.
So you cannot have your cake and eat it too. Currently this is not very good for the combination of GWT and lib-gwt-svg. GWT has not evolved yet, its widget library is designed for the old version of the browser, so GWT apps probably will work better in compatibility mode. However lib-gwt-svg is clearly designed to work in IE9 mode, because it requires SVG, only available in this mode. This is why (I think) so few apps currently work: as soon as you start doing GWT UI in IE9 mode, it breaks. Probably the GWT team will have to address IE9 in IE9 mode as a completely new user agent, which is a lot of work. There are chances most apps will run unmodified once this done. To encourage google engineers, you can vote for issue 5125 to show your interest in the topic (click on the star next to the issue number).
The port of lib-gwt-svg-chess to GWT 2.1 has highlighted an interesting fact. The application makes heavy use of java longs, notably in the attack tables of the carballo chess engines. At the time the code was written, the time to initialize the attack tables turned out to be so long (around two and a half minutes) that I had to pre-compute them, causing a big one-time penalty in the application download size (it was a 5MB download, somewhat mitigated by the use of HTTP deflate header, see my previous post of the topic). Since then, GWT 2.1 has introduced a revamped emulation of java longs, and browsers javascript engines are now much faster. I have been able to get rid of the pre-computed tables and compute them on the fly. The execution time for this part of the code is now:
| Browser |
Ellapsed time |
| Firefox 3.6 |
23s |
| Opera 10.63 |
14s |
| Chrome 7 |
0.5s |
| Firefox 4.0b7 |
3s |
This certainly beats downloading 4MB of attack tables.
lib-gwt-svg-samples and lib-gwt-svg-chess have been fully ported to GWT2.1 and I am releasing today these new versions. These applications were already working with GWT2.1 but they were still using deprecated classes for UI layout. They have been transposed to a 100% CSS-based, strict-mode layout, so the resizing should be faster and the layout more consistent accross browsers (see my previous post on CSS layout for SVG elements in GWT applications). I have also pushed the code of lib-gwt-svg-samples to the maven central repository.
To improve the ease of use and accessibility of lib-gwt-svg, lib-gwt-svg version 0.5 is now available on Maven central repository (http://repo2.maven.org/maven2/org/vectomatic/lib-gwt-svg/)
Though I will keep making it available from my own Maven repository (http://www.vectomatic.org/mvn) and from various other HTTP download locations (http://code.google.com/p/vectomatic/ and http://code.google.com/p/lib-gwt-svg/), retrieving the library from the Maven central repository is the preferred way as it is more reliable and will have the most up to date version.
A note to the early adopters of version 0.5: the version available from the Maven central repository and the version available by other means have a slightly different POM (the code itself is 100% identical). This is because POMs of projects on Maven central repository must follow a strict set of guidelines and some changes were needed for acceptance of lib-gwt-svg. I did not want to change the version number as this is the only difference. If in doubt, use the version from the Maven central repository ; it is now cryptographically GPG-signed.
I am releasing today version 0.5 of lib-gwt-svg. The new version contains many new features.
- The API has been migrated to include the lastest update from the SVG specification (SVG 1.1 second edition, W3C Working Draft 22 June 2010). See the release notes for details of the API changes.
- Documentation captured from the SVG specification has been translated to javadoc and injected everywhere in the API. All the non-W3C APIs have been documented. Many links pointing to the W3C spec have been added also.
- Exceptions declared in the specification have been mapped to java exceptions and the corresponding throws clauses have been added to the specification. The article on lib-gwt-svg design has been updated to reflect the design decisions behind these changes.
- Many new helper methods have been introduced (xpath utilities, DOM-level 2 related methods, graphical methods).
- An SVG validator has been integrated. It is enabled by default and checks at build-time all the SVG passed as SVGResource, ExternalSVGResource and inlined in UiBinder templates. The SVG validator is based on the experimental XML schema provided at W3C with custom fixes and improvements. It is possible to disable validation with the proper annotation or UiBinder attribute.
- The library is now based on the GWT 2.1 final release.
|
