Eventually, what will happen is a pluggable editor system and swapping between the new Mini UI and the old standard UI. The pluggable editor system will enable switching between the existing VectorEditor and OnlyPaths editors as well as SVG-edit. Possibly, OnlyPaths will be phased out as SVG-edit supports every feature of the former as well as many more. The priority editors with the new version will be VectorEditor (the Mini UI editor, based on Raphael so it works fine cross-browser, but is also much more limiting than the rest, including OnlyPaths which it partially replaces). SVG-edit is an awesome project which is being actively developed, and will add new features that may make the Ajax Animator viable for more than just stick figures. New features that will come from the transition could include Gradients, Curved paths, Wireframes, Zoom, Groups, Align tools, Rotation and Resizing (without bugs!), Polygon/Polyline editing, to name a small subset. It’s likely that SVG-edit will have far more features by the time it’s fully implemented. It’ll be awesome.

The SVG-edit UI won’t fit well with the Mini UI (which I actually like more), so the classical UI will be revived.

So I tried to get svg-edit to work with svgweb’s flash shim (IE support). Sadly, it’s a total failure!

http://antimatter15.com/misc/svgweb-svgedit/svg-editor.html?svg.render.forceflash=true

I only got far enough to get drawing lines, paths, polygons and rectangles working. Ellipses and text do not work. Selecting a shape shows the tracker, but if you drag it then it just flies over to (0,0) and dies. Partly because I didn’t spend any more than an hour getting the port to work, but the issues I’ve encountered is that svgweb doesn’t implement shape.getBBox() (but it did provide shape._getX(), shape._getY(), shape._getWidth(), and shape._getHeight() so it wasn’t hard to implement that). Then was that since it’s using a flash shim, the events which they hook on the container with jQuery only show the evt.target as the <embed> which the flash resides in. But I got a strange hack where you have 2 copies of the event listeners and kill the selects from the jQuery one, but doing that makes unselecting impossible.

So I don’t actually have wave yet, but for all 2 of you (likely less) who have used pygowave, an open source third party implementation of the wave protocol. So there was how I developed it, I read through the APIs and tested on pygowave. So what does VectorEditor do that svg-edit and… erm… svg-edit don’t do?

First, VectorEditor for wave is really really real time. Waaay more real time than svg-edit (not really). But VectorEdit (VectorWave might be a nice name.. I’m going to try using that name from now on in this post) transmits the data such as even while the shape is still being drawn, rotated, or moved (rotation needs work). Another nice feature is that the transitions are animated so things are even more seamless.

Another important feature is shape locking. So when someone selects a shape, it gets locked and can’t be edited by anyone else. If anyone tries, an alert box appears saying “Shape shape:5sdfwef98dfe3ssdf is locked by user antimatter15@pygowave.p2k-network.org”. svg-edit (the latter) doesn’t support moving things after they’re created so it doesn’t really matter then, and I’m quite certain the former doesn’t do any type of locking.

And lets not forget the likely most important, yet totally untested feature that seperates VectorEditor from the rest: IE support, which is inherent since it uses Raphael for rendering, but it may not be necessary since google may be making some shim-type system of hacking svg awesomeness onto IE and making the whole VectorEditor project useless.

So if you want to try it out, go to pygowave, sign up, create a wave and add the