CodeDread Blog » Google

Full Flash in Froyo

Jeff — Wed, 28 Apr 2010 04:32:11 +0000

[clipart][clipart]While it sounds like the name of a bad porno, it’s clearly good marketing strategy by Google to bring content authors to the Android platform and to court tool-maker Adobe.

But I still say that the introduction of the iPad is a signal of doom for Flash-as-a-format. On the other hand, as Adobe gets more serious about producing HTML5, SVG, Canvas, JavaScript from their Flash IDE, well…

Searchable Buzz?

Jeff — Sat, 03 Apr 2010 01:32:28 +0000

[clipart]I have a nice Twitter search feed for SVG that has been enormously helpful to me. I haven’t signed up for Google Buzz yet, but I’d like to search through Buzz for mentions of SVG. Is there a way to do this? Isn’t Google a search company?

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.

The Next Next Browser War

Jeff — Tue, 05 May 2009 01:38:30 +0000

I think the next next browser war will be about how to integrate online services into the browser itself – search plugins were only the beginning. As more and more people rely on things like GMail, Google Docs, Google Reader, and Google Maps it will only be natural for Google to integrate its online services into its Chrome browser. The question will be whether this is anticompetitive at all in the sense that the “hidden” APIs in Windows were considered anti-competitive. I do think Google will make its server-side hooks open and transparent (because it benefits by having other browsers integrate their services).

Google Docs: Now With Extra Coolness

Jeff — Mon, 30 Mar 2009 10:41:56 +0000

In case you missed it, Google Docs was recently upgraded with a Draw Chart capability. This was, in my opinion, the biggest reason to still use desktop software like Microsoft Office. The best part? It uses SVG to get the job done (and VML if you’re still using IE). Bravo! Encore!

Thoughts on the future of this feature? Here are some things I want:

Please allow the author to extract the drawing as an SVG file from the service (currently Firebug is the only way I could figure out how).
Fill gradients (Linear and Radial), please

And yes, there are privacy concerns with an online (aka ‘cloud’) service like this – I’m not implying you should use this for everything – but for the occasional document that you want to use for collaboration, it really does the trick.

Now if only I could get them to update their Spreadsheet service so that I can use it offline…

Trying To Get Things Done

Jeff — Mon, 16 Feb 2009 15:35:03 +0000

I’ve struggled a long time with trying to come up with the perfect solution for tracking my Things To Do. For the last several months I’ve tried to use a physical notepad and small pen in my back pocket, but that’s literally turning into a pain in the ass. Here are my requirements for a digital system:

View and edit from any computer connected to the web in a password-protected fashion
View and edit locally from my personal computer when offline
View and edit from my mobile
Automatically sync to one central list
Private with occasional times when I might want to share
Ability to arbitrarily categorize, sort, filter

That last requirement really kills any plain-text solution without some other higher-level tool/markup.

Now that I have an Android phone with a WebKit browser, requirement #3 becomes easier to fulfill.

Google Docs actually comes the closest to meeting all the above requirements were it not for one important thing:

Google Docs does not allow you to edit spreadsheets offline!

I’m sure the Google engineers are working hard on this important feature, but describing the existing application as ‘available offline’ is kind of stretching it at the moment.

So… What’d I Miss?

Jeff — Sat, 31 Jan 2009 04:52:31 +0000

So having gone through my 1000+ unread feed items, emails, blog comments and sundries, here’s what I think I missed while on our pilgrimage to worship a mouse in the south. Feel free to clue me in further in the comments below. Oh, and the vacation was fantastic, fwiw, though I did miss internet access that wasn’t filtered through the foggy and tiny lens of WML. I gots to get me one of them new-fangled phones that can browse the real web real soon now.

SVG Support Tables Now Interactive

Someone mashed together the data I publish with my SVG support tables and made it much more interactive and useful! Great! That’s what makes the web so cool: sharing. Now to see if I can break his scraping script… Joking!

IE9 Likely To Support SVG?!?

As “reported” in Wired and Ajaxian: Golly. How much? When? What version/profile? Sorry, but it seems that this is a misinterpretation of the standard SVG party line from Microsoft. Mumble, grumble, integrity… journalism… something, something, mumble…

More Mozilla SMIL Progress

Brian Birtles posts on the latest progress on Mozilla implementing SMIL-in-SVG. I’m hoping to see SMIL pick up, particularly as browser native support improves further. Of course you can get a headstart on this by using the FakeSmile shim right now in 4 of the 5 big browsers.

Qt Winning Votes?

Doug seems to agree with me that a LGPL for Qt could be a big game changer. I admit, I’ve always had a soft spot for Qt, but the recent news that it will be available to commercial projects without purchasing a license from Nokia is getting a lot of people excited – even heavy fans of Java

Google I/O Registration Open

I might actually try to attend the Google I/O conference this year in May. Rob and I tried to get our ducks in a row last year but the planning never crystallized. I’ve been doing some playing with Android recently, so there’s actually a reason for me to go this year.

skia

Jeff — Mon, 08 Sep 2008 02:49:42 +0000

Alp Toker, one of those graphics heavy hitters, has woken up to give us a nice summary about the ‘skia’ graphics library which Google uses for the Chrome browser. I like that it has animation and SVG awareness ‘out of the box’, but it probably won’t be a major player until it’s fully ported to all the major desktop platforms and has matured a little.

More About Chrome

Jeff — Wed, 03 Sep 2008 01:41:14 +0000

Things I Learned:

They borrowed some UI concepts from Opera and IE (controls and address bar inside the tabs, speed dial, paste-and-go) but I think they’ve done some things better. For instance: the default home page requires zero user interaction, the status bar is only present when you hover over a link, tab cycling makes sense and requires zero thought.
They really didn’t want to introduce another rendering engine for developers – so Google is simply using WebKit, it won’t be a fork
No tie-ins to Google Services installed by default
They’ve been working on it for two years
V8 will eventually make its way into Android
They haven’t made very many contributions to Webkit, but are fully committed to doing so. Their plan is to build Chrome off the WebKit tip
Extensibility – though they obviously support traditional browser plugins and they have plans for a richer extension API – it won’t be in the Beta.
UA String is: “Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13″ =>Google, please work to shorten the UA string, not lengthen it (is there really any valid reason for “Safari/…” to be there?)
The browser is fast. Transition is seemless. I like that the default home page requires no user interaction to generate. Ctrl+L, Ctrl+K, Alt+D, Ctrl+T all work as I expected.
They are using an older version of WebKit (older than Safari 3.1 it looks like) as there are two SVG-related rendering problems with my site that I thought were long gone
They have a sense of humour (open up the Chrome Task manager and see the link at the bottom)

Further Exploration:

I’m curious how browsers like IE and Chrome are ensuring that access to the browser cache is shared efficiently across all processes?
I’d like to learn more about the ‘cross-platform’ graphics library that they are using, does it support hardware acceleration?
Are other browser vendors worried that the editor of the HTML5 spec is now an employee of a browser vendor?
What are Google Chrome’s plans for feeds? At the moment, there isn’t even any auto-discovery

Google’s Chrome

Jeff — Tue, 02 Sep 2008 03:47:13 +0000

Google is going to release a new open-source web browser tomorrow (Sept 2nd, 2008) called Google Chrome. Lots of information contained in forty pages of this comic book. The rendering engine is WebKit, but it has its own JavaScript engine (V8) that compiles the JS into ~~byte~~machine code and uses more efficient garbage collection. It also follows the thoughts of the Internet Explorer team of putting the tab at the root of the UI and letting each tab be its own process (not just thread). Oh, it comes with Google Gears pre-installed too.

This all sounds good: security, stability, anti-phishing, sandboxing, ‘superfast’ JS. Of course there’s only one true test though.

At first I was wondering if this was a fork of WebKit, but I think the only thing that would make sense would be for Google to work in parallel with WebKit (continually updating Chrome’s rendering engine with new versions of WebKit). Everything else would be part of the Chrome open source project. If you’re in the know, drop a line below.

Ok, I’m happy. A completely open source browser that supports SVG and is (sort of) co-sponsored by two big companies with lots of cash (Google and Apple).