Monthly Archives: July 2010

Fitting Eclipse into my world

As I blogged a few days ago, I’ve started working on a game engine using open source bits. Part of it is just to satisfy my hunger to learn more about game development, but the more practical benefit of this effort is to better understand the plight of the C/C++ developer using the CDT on a real and fairly sizable project.

And I have my first lesson. It came about thanks to git. I have the source checked into a git repository out on github. Now, since the root of the game engine is open source libraries, I was working in the command line to extract them into the git repository. As a result I got used to using git from the command line, including adding a .gitignore so that git wouldn’t check in my Eclipse .metadata directory and any directories containing build output.

I then started setting up the projects as CDT projects and started working in Eclipse. And I gave the Helios egit plug-ins a try. Unfortunately, they currently don’t support .gitignore and as a result I got weird results that caused me to lose trust in egit, like ?’s on the folders I have listed in my .gitignore. Or did I forget to add them there? Not sure. I have to go back to the command line to look. At any rate, I ended up staying there and now I just use git from the command line. At least until egit 0.9 comes out with .gitignore support and I’ll try again.

But this article isn’t about egit. It’s about Eclipse and how developers who do C/C++, especially experienced ones, work. The command line and command line tools are still a very important part of the development cycle and Eclipse and the CDT need to deal with that.

I see a lot of functionality in Eclipse assuming that projects are the root of your life. Well, it’s not in my case. I have a git repo which contains directories that contain projects and there are some that do not. There’s even a README file at the root and some files to help me build for Android using CMake.

I think there’s a concept missing in Eclipse. We can equate the root of my git repo as a workspace. But then there are things in that workspace, files and folders, that aren’t projects. I would like to be able to browse them, and maybe even edit the files, without having to go to the file explorer. Essentially I need a file navigator rooted at the workspace. I’m not sure whether we need a separate view for that, or to just allow Workspace roots to have IFiles and IFolders and make them navigable in the project navigator.

I’d like to hear other people’s experiences, especially those who try to mix Eclipse with command line development. Is this something that would be useful? Are there other things?

Happy 100K CDT!

I originally sent this in an e-mail to cdt-dev. But it’s info others might find interesting.

Hey gang,

Just to let you know we passed 100,000 downloads of CDT today and to pass along congrats!

And, looking at the stats, there’s some interesting information there.

First, where do people get the CDT?
– 74,300 from the Eclipse C/C++ IDE package
– 6,400 from the Eclipse Linux C/C++ IDE package which includes the Linux Tools stuff as well
– 13,700 from the Helios train repository
– 2,200 from the CDT repository
– 2,700 from the CDT master zip
– 1,000 from Wascana (w00t!)

So that’s about 80% from the Eclipse packages. There are a couple of things I get from that.
– People want a quick and easy way to get the CDT and the Eclipse web site funnels them there.
– People who use CDT with Eclipse are CDT users first. Much fewer start with a different Eclipse package and add CDT to it.

And for the platform breakdown.
– 59% Windows
– 34% Linux
– 7% Mac

Again, the Linux number continues to be much higher than we’ve had in the past, which could be attributed to more developers moving to Linux, or people are moving back to Visual Studio on Windows. I’m pretty happy with the 1K so far for Wascana. And I’m hopeful at getting a Windows debug solution with Visual C++ support for Indigo (thanks to work Eugene from Wind River has done in TCF) which may change things.

Also the Mac number is only slightly higher than in the past. Other than fixing a few bugs this release, I think we’re still missing the big carrot, Objective-C. Unfortunately, there isn’t enough investment in this area for that to change any time soon, so it is what it is.

All-in-all, pretty good numbers for the summer. We usually get an explosion in the fall when the kids head back to school which validates my grassroots strategy. We’re getting a hold of the kids early and making them Eclipse savvy so that when they enter the workplace, they’ll carry forward the word there and give our employers money :).

Next report at 200K. We’ll see if things change as we go.

R-Evolve or Die

“Evolve or die!”. I’ve heard that sentiment a few times lately related to existing technologies that are coming under fire for being too old and ugly in the face of “up and comers” with fancy interfaces and social connectivity. But the more I think of it, is “Evolve” the right answer?

I don’t think so. The pace of evolution tends to be slow. At the start, you look more “different” than “evolutionary” and no one cares about that. No, I think you need to be “revolutionary” if you want to make a difference. And that’s hard for veteran organizations that fear risk to pull off.

A great mentor of mine once told me: “Don’t be tied to the technology”. The example he came up with was Smalltalk. We had a whole product written in Smalltalk and it was awesome. And it would still be awesome today except for one thing. The UI didn’t fit in with any other applications you may have been using. That and the companies that supported Smalltalk eventually died off. So what did we do? Well, we rewrote the whole thing with the help of standard desktop tools and languages and a huge code base we inherited in a takeover. Unfortunately the result was a big Windows app, but it got the job done and saved the product.

So what am I getting at? Well, I’ve got a renewed interest in the “IDE in the Cloud”, somewhat sparked by Google’s new experimental App Inventor for Android. I’m not a fan of the puzzle metaphor they picked, but it just got me thinking again of the power of the new browsers and web technologies and how we can apply them to the tools space. It does make the behemoth desktop IDE we have in Eclipse look old fashioned. But instead of thinking evolutionary, what would a revolutionary IDE look like in this new world?