CodeDread Blog » svg-edit

SVG-edit: One Year Old

Jeff — Sat, 06 Feb 2010 16:49:41 +0000

[clipart]One year ago today, Narendra Sisodiya started a tiny project called SVG-edit, with the very first check-in. He was trying to build a white-boarding application that could be used to facilitate online education.

Wow.

My kids couldn’t even talk at the age of one! Slackers…

It’s pretty amazing to think that this:

Can turn into this:

over the course of just one year, built in a lot of people’s spare time – but here we are!

I can’t wait to see what SVG-edit looks like on its 2nd birthday!

SVG-edit: The Secret Sauce

Jeff — Fri, 22 Jan 2010 03:26:05 +0000

[clipart]SVG-edit has far exceeded my expectations in the seven months since I’ve been working on it. The people I’ve met there have been amazing and it’s been really fun to watch the project grow both in members and in capabilities. Without the people working on it, people like Alexis (now the top contributor) and wormsxulla (whip-cracker on UI translations) and others, there wouldn’t be a project – that much is obvious. But would you like to know the secret sauce in the SVG-edit project? Of course you would.

[clipart]One of the surprising factors in SVG-edit has been using GoogleCode in combination with Subversion. Let me tell you why:

Linked Information

Everything is an issue in SVG-edit. This is the way we keep track of things to do. This is the way other people discover things they can work on. This is the way we prioritize features for a release. This is the way we identify good first bugs for new hackers to work on. This is the way we sort problems into browser-specific, usability, interoperability categories. This is even where we put requirements and design decisions.

Making almost everything an issue is good because GoogleCode has some magic that detects revision commit messages and message comments and inter-links the two. For instance, if I fix issue 436, I might do:

$ svn ci -m "Fix Issue 436: Fixed the foo thing"

This shows up in GoogleCode here and provides you a link to the issue.

Now in the issue itself, I can mark it as Fixed and mention the revision that fixed the issue:

Fixed in r1275

Once again, GoogleCode provides a link to the revision when you look at the bug.

This kind of tracking takes a little bit of discipline, but it’s not that bad and the payoff is worth it. It really helps other developers keep tabs on what’s been solved where and how.

Host It

Since SVG-edit is a 100% client-side application (i.e. everything happens in the browser, no server component), and since Subversion allows you to specify MIME types by setting properties on files, we can convince GoogleCode to host the entire project in runnable form for the purposes of demo-ing the code.

This applies to the trunk as well as any branches and tags. For instance, you can actually see the evolution of SVG-edit over time:

Or you can look at the latest trunk build.

Or you can host the file in a web page by using <iframe> element like I’ve talked about before.

The fact that GoogleCode servers host the repo and also support web serving the content is immensely powerful: it means we don’t have to administer a source code repository and we don’t have to pay for a dedicated server or bandwidth costs to demo the software. Furthermore, because it’s a browser-based app, users don’t have to download anything, they can try out the code right on the spot.

Incidentally this is also one of the strengths of a web app in the first place: Zero downloads.

Tracking Down A Regression

GoogleCode’s hosting of the svn repo doesn’t stop at branches/tags. In fact, you can look at ANY revision in the browser directly. Coupled with the fact that we don’t really require a build step means that it is very easy to track down a regression.

git has this cool feature called bisect that allows you to hunt down when a regression occurred by seeking forward/backward across revisions in increasingly smaller increments, building each revision and testing until you find the first revision in a branch that exhibited a problem.

We can do this much easier in SVG-edit using Subversion on GoogleCode. Let’s say one day we notice a problem in the trunk and we’re at r1200. Well, we might decide to try out the editor at revision 1000 to see if the problem existed then. If the problem did not exist, we hop ahead 100 revisions to r1100 – was the problem present then? If so, hop back 50 revisions to r1050. Repeat in the browser until you isolate the earliest revision where the problem occurred, then add a comment to the issue and go review that revision.

Totally amazing capability and no more difficult than changing a revision number in the browser location bar. I have to credit Narendra Sisodya, the project founder, with uncovering that little nugget.

Not a Nirvana

There are still some grips/nits I have with GoogleCode+Subversion:

Being able to serve gzipped JavaScript would be great
Being able to display the current revision number in SVG-edit
The wiki markup needs significant improvements

But this is free hosting and project management software, so I can’t complain too loudly.

Just Ship It!

Jeff — Mon, 11 Jan 2010 20:31:29 +0000

[clipart]So Alexis and wormsxulla and all the translators and anyone who opened a bug against SVG-edit should really just be proud, because SVG-edit 2.4, codenamed Arbelos, is now released. Try out the DEMO now.

For those who have more time to kill, here are a couple screencasts I tried to make that demonstrate the new features:

And there’s lots more coming in SVG-edit 2.5 (codenamed Bicorn) that we’ll be talking about in the future.

To celebrate, here’s another comic I made using SVG-edit (view full size):

Merry Christmas 2009!

Jeff — Fri, 25 Dec 2009 00:02:23 +0000

[clipart]Turned on the Christmas CSS and released SVG-edit 2.4 Beta. That should be enough

Happy Holidays to all the folks out there and talk to you next year!

Great Expectations

Jeff — Tue, 17 Nov 2009 01:40:43 +0000

[clipart]I found The Complete Peanuts 1950-1952 at the library a few days ago and wolfed that thing down. In honour, I thought I’d try my hand again at another comic done in SVG

This time, I used SVG-edit. I’m happy to say that features like Zoom and Path Editing mean that this is now very achievable. Might I dare say “fun”? Incidentally these are features that Fyrd did in his spare time. Ok, well Layers do help here too.

For whatever reason I had some issues on the trunk with some path nodes and control points becoming out of sync with the shape twice. I had to start a new Firefox tab and paste the image in there to keep editing – the modern equivalent of ‘rebooting’?

As with the previous comic, see if you can find the ‘easter eggs’ without viewing the source!

Busy Busy Busy

Jeff — Thu, 30 Jul 2009 22:52:20 +0000

There’s something comforting about coming back to your blog after spending so much time on Twitter and the like. Twitter is great for learning about new things and sharing links quickly, but writing this entry in WordPress and not having to worry about a character limit feels… cozy. I thought I’d come back to the blog and try to give an update on what I’ve been doing lately.

Despite the silence on the blog, I’ve actually been really busy with all sorts of different projects. I think I’ve got my fingers in too many pies now. And all of them happen to be related to Scalable Vector Graphics. How did this happen?

SVG-edit

As mentioned earlier on my blog, in my spare time I’ve been hacking a little at SVG-edit and its child project jGraduate. It’s now at a point on the SVG-edit trunk where you can actually pick a gradient for your stroke/fill, which is a pretty cool thing to see.

Other than myself, the list of active contributors to the project has dried up lately. This is to be expected on open source projects. So I’m looking for fresh blood to come into the project and implement some of the features we have planned for the 2.3 release. The Align tool would be a good place to start.

Scour

I’ve also been continuing to plug at Scour development, releasing version 0.16 of the script yesterday. It’s starting to feel like diminishing returns lately on that front (i.e. a lot more number crunching and code going in and only marginal improvements to SVG file sizes). This is expected. I think the majority of features related to sane SVG reduction have been implemented. There are a couple big features I want to get to:

Removing duplicate gradients (Done in 0.17)
Removing redundant path segments after precision adjustment
Parsing CSS/style elements

After that I’m expecting scour to go into a mostly bug-fix mode. If you want to propose additional features, file bugs or write some unit tests, please feel free to contribute!

SVG Open 2009

Earlier this year I volunteered to help out with the SVG Open Conference. Through some nice serendipity, we were able to get Google to host the event at their campus in Mountain View, California. The theme is “SVG Coming of Age”. There are some really cool talks and workshops planned for this October and maybe a couple of surprises so I hope to see you there. I’ll be the tall guy pulling out what remains of his gray hair.

Planet SVG

One of the things I’ll be talking about at the SVG Open is the SVG community website that some of us have been poking at for what seems like forever. The site is ‘live’ but there are many ongoing improvements I want to make to the site. One of the recent updates was that a web-based version of Scour was added. It’s not pretty yet, but it is functional.

So what are you working on?

Embed an SVG Editor in Your Web Page

Jeff — Fri, 19 Jun 2009 17:23:12 +0000

In my spare time I’ve been having fun contributing to the SVG-edit project this last couple weeks adding really basic features like selection and dragging. The goal is a cross-browser SVG editor that you can embed in web pages that works on any modern browser. My biased definition of a modern browser: native support of SVG. I know there are quite a lot of projects out there that do an online SVG editor already. SVG-edit is still in its infancy, but that’s part of the charm I found in hacking on it.

One of the nice things about hosting it on Google Code is that you can rig the Subversion repositories to serve the proper MIME types of the files in question. This means we can have Google Code host the editor and just iframe it into our pages.

For instance, using:

<iframe src="http://svg-edit.googlecode.com/svn/tags/stable/editor/svg-editor.html" width="750" height="600"/>

here is the latest stable version of the svg-editor sitting in my blog:

You can view source, I ain’t lying. The nice thing about this link is, when I wrote this blog entry, the above iframe included SVG-edit 2.1, but when 2.2 is released my web page will automatically include it. This keeps you on the latest release but does not expose you to the potentially unstable trunk.

If you prefer to host it yourself, download svg-edit or check out the source code. Eventually we’ll host this on PlanetSVG as well – that’s the proper place for it in my opinion.

And there’s ongoing work by Vidar to turn this into a Google Wave Gadget for collaborative sketching, which would be awesome.

Anyway, if anyone wants to get this working on a legacy operating system with a legacy browser and a legacy plugin your patches would be really appreciated (modern plugins or shims would also be good). Note that it programmatically creates the SVG element inside the HTML and uses jQuery so this might be a challenge. I’d still like to see it happen though!

You can discuss SVG-edit here and report issues here.