vectomatic

Update of lib-gwt-file

admin — Fri, 02 Dec 2011 17:22:58 +0000

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

Availability of lib-gwt-svg 0.5.4 and other announcements

admin — Wed, 02 Nov 2011 21:25:16 +0000

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:

	Webkit (chrome)	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

Availability of lib-gwt-file 0.2

admin — Sat, 24 Sep 2011 19:26:33 +0000

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.

Availability of lib-gwt-svg 0.5.3 and other announcements

admin — Sat, 10 Sep 2011 09:05:15 +0000

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+.

SVG paint and stroke

admin — Sat, 10 Sep 2011 08:58:11 +0000

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:

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.

lib-gwt-svg 0.5.2 is available with IE9 compatibility

admin — Fri, 06 May 2011 19:48:12 +0000

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.

A file API for GWT

admin — Tue, 29 Mar 2011 19:34:22 +0000

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

Annoucement: lib-gwt-svg 0.5.1 availability and other miscellaneous changes

admin — Tue, 22 Feb 2011 08:30:51 +0000

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 the general purpose library lib-gwt-svg / lib-gwt-svg-samples
a repository dedicated to games (lib-gwt-svg-edu-* / lib-gwt-svg-chess)
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.

IE9 and lib-gwt-svg

admin — Thu, 18 Nov 2010 21:49:37 +0000

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).

Performance improvements of GWT2.1 for long-based computations

admin — Wed, 10 Nov 2010 18:33:01 +0000

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.