Monthly Archives: May 2010

My take on Android Keynote at Google I/O

No, I’m not at Google I/O, despite my twitter traffic during today’s keynote. Mind you that was probably a give away that I wasn’t there as even the Googlers struggled with wifi connectivity during their demos. At any rate, I was glued to see where Google was taking Android. And, to be honest, they didn’t really surprise me much as pretty much everything they announced had a rumor associated with it. It’s hard to keep secrets in this industry.

Despite the lack of surprises, there were a few interesting points that were made, and a couple that were not which gave me pause.

First, was Google TV. Yes it too was rumored and came out pretty much as was rumored. There were two things I found interesting about it. And no, a set top box based on Android isn’t one of them as we pretty much expected that eventually. No, first was confirmation that the initial Google TV boxes will be based on Intel Atom chips. What that means is the real first confirmation of an x86 port of Android from Google officials. The new Android Native Development kit r4 that also came out today also confirms it with an x86 port of the native libraries. It’s not quite cooked yet as there’s no toolchain to build with and no image to run on, but they’re there and a sign of things to come.

I guess the other thing that struck me about Google TV that I think was even more interesting was that they were running Google Chrome on top of Android on top of x86. I’ve heard rumbling about the lack of information about Chrome OS at the conference. Now, if they have Chrome running on Android for Google TV, why not run it on netbooks too? And then why have Chrome OS at all. That’s where I’m guessing there won’t be one or if it does appear, we’ll all be wondering why when you can get all that plus Android apps to boot just like on Google TV. Or, maybe, that is what Chrome OS is. We’ll see (or maybe not)…

So there were a few new things in the Android NDK for me to chew on. One that will make the CDT build integration I’ve been working on easier to do is the ability to build outside of the NDK directory tree (weird, yeah, but they previously reused the build system from the platform that is done that way). So look for that sometime in the near future. There’s also gdb support for native applications. I’ll need to see what’s needed to hook that up to CDT’s debug interfaces. In the end it’ll be a great public example of how to use the CDT in a cross compile and remote debug scenario. Not to mention it’ll be fun to use :).

CDT, Towards World Domination

Big smiley planted in the title of this one BTW.

I’ve been working on the CDT for coming up on 8 years now. It’s been quite a long journey, and what keeps me motivated is that I don’t see the end in sight yet. For CDT to be successful, the companies and individuals using CDT need to be successful. And until I see everyone happy with it, our job isn’t done.

Now there are a lot of successes already today. CDT is still a key part of the IDE strategy for a huge handful of platform vendors, especially in the embedded and mobile space. And we have nearly 600,000 downloads of CDT, so I assume the downloaders are being successful (or they’re having disk problems and need to download it all the time, maybe). But if things were so rosy, I wouldn’t be hearing all the complaints about CDT and Eclipse in general that I do.

The biggest complaint I get from the user community is how hard it is to set up CDT for their platform, especially developers using Windows. That’s where Wascana comes in. There’s also a variety of environments that don’t come with out of the box support, like Qt and Mac Cocoa.

Commercially, a lot of what I hear is about customers who would still rather use command line tools than our commercial IDEs. That tells me two things. One, that these people just don’t like change or learning new things. But more importantly, it tells me we don’t provide sufficient cost/benefit for them to make the jump. And really, the benefit has to be much greater than the cost and that means not simply doing the same things you can with the command line, but taking it to a next level that an Integrated Development Environment gives you. I joke with the product managers here at Wind that we need to put the capital back in the ‘I’ in integrated. I’m not joking…

So to help bring the nay-sayers on board, my strategy with the CDT is to make it ubiquitous. I’d like to see as many developers as possible in the world able to used it, and like to use it. That way, when we come to them with a commercial offering, CDT in the product becomes a value point.

Ensuring the CDT works out of the box is a big part of that strategy, especially for platforms that don’t have commercial support. Linux is covered very well by the Linux Tools project at Eclipse, Wascana for Windows, and I am trying to find time to get it working well for Mac (Objective-C support included). Qt is a natural for cross platform development, so is CMake and Autotools build environments. And I’m helping with CDT support for Android native development. These are things CDT should support out of the box to enable my plan for world domination :). And that’s what motivates me to keep plugging away.

Wascana Lives! on Eclipse Labs

When I first heard of Eclipse Labs, I was thrilled about the idea. Having a central hosting site where we can gather all the open source projects that skirt the official Eclipse site is a great way to build visibility for these projects and a great way to promote the creation of new ones.

Well, today, Eclipse Labs is a reality. And, as I was one of the beta testers for it, I’m pleased to announce that I have moved the Wascana Eclipse C/C++ IDE for Windows Developers over to it. I really struggled with Wascana over at SourceForge where there’s a low signal to noise ratio, but thanks to Eclipse Labs, it should help people find it and realize it’s place in the Eclipse community.

Right now, I’d consider Wascana still beta quality, mind you all of the packages are released open source projects so I know they work. But the key behind Wascana is a p2 repository and the org.eclipse.cdt.p2 plug-in that knows how to unpack tar.bz2 files. This plug-in is part of the Helios Eclipse C/C++ IDE package so all you need to do is get that and put the URL to the repo into p2 and install away. Feel free to hop on over and take a look at the Wascana site at Eclipse Labs.

In the future, I hope to figure out an even easier way to install, possibly similar to how Subversive gets it’s SVN connectors. At the very least, I’ll be posting an NSIS installer containing everything you need up to the Wascana site. This should all be in place for the Wascana 1.0 release around Helios release time.

Update: As I was writing this blog, an issue I was having with the downloads have been fixed. Wascana 1.0 Beta1 is now available on the site.

Thanks to Ian Skerrett and Google for getting Eclipse Labs together. As I mentioned in the blog post I posted when I first heard of it, this is going to be a game changer. I can’t wait to see what projects pop up there.