The state of lib-gwt-svg and lib-gwt-file

Dear lib-gwt-svg and lib-gwt-file users,

As you probably have noticed, the rate of updates and support responsiveness on the two libraries has declined in the past few months. There are two main reasons for that:
1/ It reflects the state of GWT development and Java development in general. Google has transferred the responsibility of the framework to a committee. The committee has announced bold and distant moves (GWT 2.6 in Q4-2013, followed by GWT 3.0 in H2-2014). I find some of the new directions interesting (like the focus on mobile where indeed GWT could be interesting), but until the promises materialize, I take a wait and see approach.
2/ I have pursued other interests myself, and revisited native JS development, and I really like what I found. I have ported
lib-gwt-svg
to JS, and, in combination with a good IDE, it gives me the same level of comfort I had GWT / Eclipse. If you are curious, you can read more in this post.

Along with these updates, I am also upgrading my own programs based on lib-gwt-svg and lib-gwt-file: lib-gwt-chess, svgreal and lib-gwt-svg-edu. The updates mostly address Firefox compatibility issues, caused by recent changes in Firefox which broke the code. The update to lib-gwt-svg-edu is also an attempt to introduce responsive design in GWT using media queries. Depending on the format of the page (landscape or portrait) the layout of the game controls will adapt to give the greatest possible screen area to the game itself. As you can see if you look at the code, implementing something like this in GWT is far from elegant (one could do much better with native JS). I hope future GWT versions will provide a improvements to GWT CSS integration.

Firefox OS development and OpenWebApps

I am launching today two new sites dedicated to FirefoxOS applications and FirefoxOS games.

http://www.fos-apps.org
is a web site dedicated to providing open-source FirefoxOS compatible applications.
http://www.fos-games.org
is a web site dedicated to providing open-source FirefoxOS compatible games.

Even though the main focus of these sites is FirefoxOS software, the apps I intend to publish on these sites are OpenWebApps, which means they will run on most modern browsers (Chrom(ium/e), Safari, IE) though some of the features may work differently on these browsers until these browsers implement the required Web APIs.

The first application available is Push puzzle.
http://push.fos-games.org

I ported my original GWT application (lib-gwt-svg-edu-push) to pure JS and wrote a lot of code around it to turn it into a true app:

  • global redesign to turn it into a web/tablet/phone friendly app
  • ability to create new levels using any image (bitmap and vector)
  • persistence of new levels and game state (using IndexedDB).

In the process, I had to convert lib-gwt-svg into a JS library (called libsvg.js). I wrote a separate post about the conversion process.

I hope you will enjoy this new app

Lukas

libsvg.js: porting lib-gwt-svg apps to native JS and Firefox OS

I recently purchased a FirefoxOS phone and wanted to create my first application for the device. I already had a large legacy of GWT code based on lib-gwt-svg and lib-gwt-file and wondered if I would be able to reuse some of that and in what form.

I quickly realized that I would not be able to keep GWT as a framework to address FirefoxOS devices. There is no GWT plugin for FirefoxOS devices, and developing in web mode or super dev mode means several-minutes build / compile / test cycles which are just not workable for me. Furthermore, the lack of encapsulation for all the new browser APIs (IndexedDB, web activities, AppCache…) means I woudl had had to develop a GWT encapsulation layer for this before getting started.

The altenative seemed a daunting too: leaving java, Eclipse and code completion behind. I tested various JS IDEs (NetBeans, Aptana, Eclipse + JS, WebStorm) to see evaluate their code completion module.
I decided to use WebStorm as it is capable of parsing jsdoc comments to infer types of variables in a lot of cases and offers auto-completion and contextual documentation when writing code.

To leverage this, I have ported lib-gwt-svg to Javascript and called it libsvg.js. I found out there is really no need to port lib-gwt-file to Javascript, at its using the File API directly in JS is actually straighforward.

lib-gwt-svg has actually two parts: one part is GWT wrappers for the SVG Javascript API, adorned with documentation extracted from the spec and injected at the proper location as javadoc comment ; the other part consists in miscellaneous utilities for common SVG operations, such as rectangle intersection or vector normalization.

libsvg.js comes itself is made up of two files:

libsvg-ide.js

is just a collection of JavaScript prototype declarations, adorned with documentation extracted from the spec and injected at the proper location as jsdoc comment. If your IDE is smart enough (Webstorm actually is), it will be capable to infer the type of js variables and provide autocompletion and contextual documentation based on this file, as well as warn you of errors if you do not respect the method signatures. The file is not intended to ever be loaded by an actual web browser. It just lives in the IDE as a helper, you do not need or want it in actual production.
libsvg.js

contains the utilities part of lib-gwt-svg, as well as helper methods to help the IDE infer the proper type for JS variables method.

In libsvg.js, there are two main classes of helper methods provided.

Factory methods

have been added to the Document prototype to let you create SVG elements from scratch:

// Create a circle using the extra factory method added to the Document prototype.
var circle = document.createSVGCircleElement();
// Now the IDE is aware of the type of the circle variable, because it has read the prototype and javadoc of SVGCircleElement from the libsvg-ide.js file and knows createSVGCircleElement returns a SVGCircleElement. The line below is typed with autocompletion.
var circle.cx.newValueSpecifiedUnits(SVGLength.SVG_LENGTHTYPE_PX, 100);
Hinter methods

have been added to the Element prototype to let you specify the type of elements you retrieve using calls to getElementById, XPath, DOM traversal. Technically, these methods do nothing except return the element itself, but they do it with a properly crafted jsdoc comment which the IDE can use to infer the type of the element. This presents an overhead, but it is tolerable in most cases and JS optimizers are probably capable of figuring out they are useless at runtime and eliminate the extra code altogether (though I have not verified this claim !).

var circle = document.getElementById("c1").asSVGCircleElement();
// Now the IDE is aware of the type of the circle variable, because it has read the prototype and javadoc of SVGCircleElement from the libsvg-ide.js file and knows asSVGCircleElement returns a SVGCircleElement. The line below is typed with autocompletion.
var circle.cx.newValueSpecifiedUnits(SVGLength.SVG_LENGTHTYPE_PX, 100);

Using lib-gwt-svg, I was able to port the SVG part of my game fairly easily to JavaScript. The truly hard part was to redesign the game itself to turn it into an application and to make it usable on devices such as smart phones and tablets. The game is called Push Puzzle and can be run online from a FirefoxOS phone or most web browsers.

New version of lib-gwt-file

Hello,
I am releasing today a new version of lib-gwt-file, which fixes a few bugs on IE, Opera and Webkit. I have tested the sample application with FF17, IE10, Chromium 25, Opera 12.11 and it works fine on all these platforms. Long live HTML5 !

Updates for GWT-2.5.0 compatibility

I am releasing today a new version of most my GWT libs, apps and games. The update is mostly to preserve compatibility with GWT-2.5.0, and the new gwt-maven-plugin 2.5.0. You can look at the release notes for more details. The code is available in GitHub and maven central.

updated version of GWT libs, apps and games

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

vectomatic moves to github

I have been working during the past weeks on a significant upgrade of the tooling underlying vectomatic, with the following goals:

  • Make it easier to contribute to the projects.
  • Make it easier and faster for me to release new versions of the projects.

To achieve that I decided to make the following changes:

  • Replace subversion with git. In the process, I decided to split my big vectomatic svn repository into separate git projects.
  • Replace googlecode with github.
  • Use jenkins to automate the whole build process.
  • Make better use of maven by factoring project configuration into two parent poms (vectomatic-parent and vectomatic-gwt-parent).

Project sites

The official project sites remain unchanged:
http://www.vectomatic.org

Downloads

The miscellaneous project stable builds can be downloaded from these locations:

SCM repositories

Developers can collaborate to the projects by forking the git repositories at github. Some older projects (vectomatic and vectomatic2) remain hosted at googlecode at the moment. You can find a detailed map on the Vectomatic tooling and repositories tools page.

Bug reports

Bug reports and feature requests should be filed using either github or googlecode, depending on where the project is hosted.

Discussion groups

Discussion and questions are still hosted by the usual google groups.

support for native svg drag-and-drop

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.

public static final String SVG_FEATURE_TOUCH_EVENTS = "http://www.vectomatic.org/TR/SVG11/feature#SVGTouchEvents";
public static final String SVG_FEATURE_DND_EVENTS = "http://www.vectomatic.org/TR/SVG11/feature#SVGDndEvents";

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

if (DOMHelper.hasFeature(SVGConstants.SVG_FEATURE_DND_EVENTS)) {
   ...
}

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

svgreal 0.2.1

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.

New site organization

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.