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:
a repository dedicated to a SVG editor application (vectomatic2)
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.
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.
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.
Many exciting news to begin this month of October !
First a new release of lib-gwt-svg (version 0.4.9). It fixes a few bugs, adds more classes to provide a a more complete DOM level 2 access, adds a few utility methods. It is based on GWT 2.1 M1. If you need it for other levels, please contact me. More on this topic here.
Second, I am really happy to announce the release of my first version of vectomatic2, an online svg viewer. Vectomatic2 is the reason I started lib-gwt-svg in the first place, as I needed a GWT toolkit to manipulate SVG. I plan to make vectomatic2 evolve into an SVG editor, so expect new release in this direction in the coming weeks / months. Vectomatic2 works on all SVG enabled browsers with GWT support (this means: IE9 not yet, but this will come soon hopefully). More on this topic here.
Third, I am also releasing a new version of my SVG games. I redesign them completely to make them more modular, so that I can add new games more easily. I have also solved my resizing issue and come up with a good way to use SVG and CSS to make SVG UI resizable. The maze game is now available for Chrome 7 users (and it is super fast !). I have not been able to port the other games yet as Chrome 7 has still too many SVG bugs (problems with transforms, and use elements with transform). But it will come eventually. More on this topic here.
I am very excited to announce the release of my dearest open-source pet project: vectomatic2. It is a rewrite of my earlier vectomatic project along new lines: SVG technology (based on lib-gwt-svg) and GXT UI.
It has been tested on the following web browsers:
Browser
Version
Firefox
3.x or greater
Opera
9.x or greater
Chrome
6.x or greater
Safari
5.x
Currently the features are limited to those of a viewer:
You can open arbitrary SVG files. It is connected to the RSS feed of the great OpenClipart project so that you get a fresh supply of SVG to manipulate.
You can manage several documents at the same time (which will prove useful when the application will allow cut and paste between images).
You can easily scale are rotate the images (which will prove useful when you want to work on particular detail).
The plan is to make the application evolve from an SVG viewer to an SVG editor.
If you use an old browser and cannot use it yet, you can watch this video demonstrating the program:
I have done a major re-architecture of lib-gwt-svg-edu, my educational game project. You can see the results here.
The project had become too big to fit under the umbrella of a single maven project: it was slow to compile, the various games where tied to one another, and adding more games seemed problematic. So I bit the bullet and decided to re-architecture it. I split it into several independent project:
You can work on just your game and focus on it without being bothered by the rest of the project. Notably this has enabled me to do some work on lib-gwt-svg-edu-maze and it now works beautifully on Chrome 7 too ! I hope I can port the other games soon, or at least file more Webkit bugs as I get better understanding of why they do not yet work on Webkit based browsers.
There is a potential to reuse the games in more environments. I plan to make plasmoid and Opera widget version of the games. I also would like to develop a new menu to target mobile devices.
One of the most serious problems I had been facing with my SVG apps is that the layout and sizing of SVG elements was never right. The interactions of the SVG width and height attributes, the CSS width and height properties, and the rest of the HTML elements baffled me. The behavior was erratic, never identical from one browser to the next, and I had resorted to extreme measures (add window resize handler to programmatically recompute the size of the various elements) to get a half-working and slow layout. Hopefully these days are behind me.
Here are the few rules I have been able to determine which really save the day:
Forget quirks mode and go to CSS strict mode. This means that all you applications should use a doctype declaration. HTML 5 seems to be the one to use (this will prepare your app for IE9 compatibility):
<!DOCTYPE html>
Use CSS positionning attributes intensively: left, right, top, down, along with absolute positionning and percentages. This works beautifully and most importantly cross-browsers
To see all these rules in action, you can look at the new version of lib-gwt-svg-edu games. Resizing is much faster, the application can scale to any device size. It also really makes sense now to use SVG push buttons to control your app (instead of classic image-based buttons), as they will scale properly and be rendered at your device top-resolution
