Historic Day for Linux Desktop?

I just tweeted this, but it's worthy of a blog entry because I think this will, or at least should be, marked as an historic day for Linux. Mark Shuttleworth, Ubuntu chief, blogged yesterday that they are starting a transition from an X Windows based environment to the Wayland display server. That is huge news and a huge push for the fledgling Wayland project which is starting to get a lot of love lately. Intel, who employs the main developer for Wayland, already seems committed to getting MeeGo on top of it, but this move for Ubuntu all but assures Wayland will become mainstream for the Linux desktop. And I can't wait for that!

So what the heck is Wayland and why am I so excited about it? Well I've been working with X Windows since my university days when X11 was spanking new. It had a great architecture that allowed the display to be hosted on a different machine than where the application ran. Back in the early 90's that was pretty important since workstations weren't very powerful so we still had big iron Unix servers where we ran things and being able to display them on any machine in the lab was liberating. It was the best, back in the early 90's that is.

Then entered personal computers thanks to Microsoft Windows and to some extent Apple Macintosh. As these machines grew faster and faster, it became more economical to run your applications locally. Not only that, but the graphic architecture, where display handling was part of the operating system, allowed for the desktop environments to become rich, to the point now where we have the beautiful environments of Windows 7 and Mac OS X.

Now when Linux came along, the powers that be chose X Windows as the underlying display architecture. It made sense since X Windows is open source and it does a good job. But it is shackled by the underlying architecture that made it popular in the 90's. As Mark put it, "I understand that it’s *possible* to get amazing results with X, but it’s extremely hard, and isn’t going to get easier. Some of the core goals of X make it harder to achieve these user experiences on X than on native GL, we’re choosing to prioritize the quality of experience over those original values, like network transparency."

And that's where Wayland comes it. Wikipedia describes it as "a lightweight display server for the Linux desktop. Started by Kristian Høgsberg, one of Intel OSTC member, the software's stated goal is 'every frame is perfect, by which I mean that applications will be able to control the rendering enough that we'll never see tearing, lag, redrawing or flicker'". It gives the application and window managers full control over how their content is displayed and gives them free access to the graphic hardware acceleration through OpenGL and OpenGL ES, essentially the same architecture which gives Windows and Mac their great environments.

It's going to take some time as the ecosystem grabs hold of the possibilities. It is almost certain that other Linux distributions will jump on the bandwagon, and I'm sure nVidia and AMD will do the same with their hardware drivers. But once they do, I am convinced that this will finally make Linux a real contender in the desktop space. I can't wait :).

Playing App Developer - Where to start

The mobile space just doesn't seem to stop being more interesting by the day. It's got me hooked, and I'm not sure why other than it's fun to be a part of, even if it is in my hobby time. I keep trying to integrate it into my day job but it's not clicking :). Instead, I am trying to become an amateur game developer in the few hours a week I get time for it at home. If nothing, it helps me feel a part of all the excitement.

As I march along my journey, it becomes quickly clear the first choice app developers face when getting in the game. Which mobile platform do I start with and what do I do about the others? From where I sit, the choice is obvious. I have an Android phone (actually I have two but my first one is a Roger's HTC Dream that's stuck on Android 1.5 which isn't very useful), and since the SDK is freely available I am starting with that.

But I can't ignore Apple's iOS. It still is the mobile industry's darling and likely will be for a long time. The problem there is that I don't have a Mac which is a pretty high barrier to entry IMHO. But that's OK. There seem to be a few people in the blogosphere who know how to get Mac OS X running in VirtualBox. But when it comes time to actually deliver something (assuming I ever get that far), you'll need the real thing.

It's pretty sad to see what's happening to Symbian. I have friends with skin in that game so I'm not going to say much, other than I agree with the prognosticators. Throwing your product over the wall into the open doesn't make it an instant success. At the end of the day, open source doesn't win mindshare. Having low barrier to entry and a good chance of getting good volumes do. Symbian is a technically complicated app dev environment. Qt will make that better. But if you're programming to Qt, then Symbian doesn't matter much since MeeGo also runs Qt. Which makes MeeGo something to watch out for.

RIM is an interesting choice. But people don't think of RIM phones as gaming devices. The new tablet might change that, but it's not clear you can write native code for it, which, of course for me being CDT Doug, is a must.

And the same is true for Windows Phone 7. It appears you need to use C#, or at least managed code. I'll need to dig into whether managed C++, if it even still exists, would work. But Microsoft is the king of walled gardens as much as we look at Apple today. But Microsoft also loves game developers, so we'll see how that platform evolves.

So it's an interesting array of choices and the pieces are all in motion and it's a bit hard to guess how it'll all turn out, which is why it's fun to watch. Of course, I do need to mention that I'd prefer to use the Eclipse CDT and tools from the Eclipse ecosystem to build my game for all these platforms. But that is only slightly less disjoint than platforms are. As I've often said, I'd love to have a single Eclipse project with build configurations and debug integrations for all of these. That's the vision, anyway. And playing in the mobile space has me convinced how important that really is.

Users versus Vendors, or is it Users and Vendors

One thing I've been noticing lately on the CDT project that's probably happening with other projects at Eclipse is that more and more contributions, contributors, and even committers are coming from companies that are users of Eclipse technology. When we started the CDT and for many years we were driven almost exclusively by vendors that had commercial products that used the CDT. But now we have this very interesting mix and that is really changing the dynamics of how we work.

But you could see it coming and Eclipse is setup up to promote such growth. It started as bug reports, then slowly patches started getting attached to those bug reports, then those guys writing patches started contributing more patches and participated in the mailing lists until we finally voted them in as committers so they could apply their own patches. And that's how it's supposed to work. That's how you grow your community. And that's how we've reached the rich diversity enjoyed by the CDT project.

But as I mention, there's an interesting dynamic that's happening. The vendors are still trying to make money selling CDT-based products. Those users used to be potential customers of those products. However the economics of open source makes it actually cheaper and gives them more control if they get their tools and platforms from open source and staff a few developers to maintain and grow that software. When you have a user base that numbers in the thousands, I can see it. And there are quite a few of those companies, especially in the embedded space.

So what used to seen as differentiating features for vendors is still functionality that is desired by these user contributors. And of course, they would rather see that functionality implemented in the open where they can share it amongst themselves and anyone else who could potentially contribute. So as they organize, the tools vendors are looking on with dread. We have always fought to stay above the open source line with our value add, but it's becoming more and more difficult. And that line is growing exponentially. It's certainly a wake up call for us who get paid out of product revenue.

Has the industry changed making us dinosaurs or is there still value that we can provide that users will pay for. I think we still can make money, but we definitely have to change they way we think. It's no longer about who has the best features. It's what it should have always been about, who makes their customers the most successful. Our user contributors know that as that's exactly what they are paid to do. We vendors need to find our place there too.

CDT Summit Report: What to do about the Eclipse Platform

We had a lot of heated debate about what to do with the Eclipse Platform and the troubles we've had trying to contribute to it to allow it to meet the needs of our customers. There have been some successes, there is no doubt. We have flexible resources in 3.6. We have flexible debug in the platform for quite a while now. So we are very thankful for that.

But we're still not in a good place yet. We're still really struggling with build. CDT builds are complex beasts involving external compilers and linkers and other utilities and generators. Builds tend to take a long time. My standard sized C++ project porting the Irrlicht game engine to Android takes about a few minutes to do a full build with a Minimum 3-5 seconds for a one line change. It's not "instantaneous" like Java and dynamic language builds tend to be. So features like automatic builds never made sense for us.

Also, our builds tend to be managed by external tools, 'make' in particular, that manage the "delta" of what needs to be built for us. The resource delta that the platform provides is useless in those cases, other than as an indication that something has changed and we need to invoke make. Mind you we tend to always build anyway just in case we have external files that may change that aren't being tracked by Eclipse.

That leads to the oddest workflow, clean, which in the C++ IDE's we've used in the past, means just that. Remove all previous build output. But since that also clears out the Eclipse build state, it invokes a FULL_BUILD right away to rebuild it, which we then interpret as the need to call out to make which then puts the build output right back. And if we ignore FULL_BUILDS, we miss the initial build. It's a mess.

The good news is that we have people working on fixing these things, and have opened bugs against the platform and attached patches to them. But it's been really slow to get them looked at or they are being rejected outright. What ends up happening is that vendors fork the platform and apply the patches they need anyway. Now that's not a healthy situation when we are trying to build an ecosystem when everyone has a different eclipse platform you need to plug into.

So what do we do about this? Is e4 the answer? No. In fact surveying the crowd at the CDT summit, no one was interested in the features that e4 brings to the table. It doesn't address the problems that we as a C++ IDE community have today. And we need to those things fixed in the Platform today, not in an incubator. Fancy UI frameworks are maybe something we need down the road, but our customers want us to get the basic workflows working well first.

So in a drunken stupor (well stupor anyway) at our celebration event I threw out a proposal to the people standing around me and then to others during the week. e4 is a fork of the platform. It was created to try out some new ideas. Why don't we create our own fork of the Platform focused on meeting the needs of the CDT community and for our fellow Tools projects that have the same needs. That way we can at least share the forks we've already created for our products. We still need to run all the same plug-ins we do today such as Mylyn, JDT, etc. So we can't go crazy and change the world. But at least we'd have control over it to make sure it meets our needs.

You know me by now. I like to brainstorm with the community. So I'm only semi-serious about forking the Platform. We are taking a serious stance on the bugs we have opened up there and I hope the Platform team will work with us for the mutual benefit of our users. We are frustrated about the lack of progress and we do need to think of alternatives. And forking the Platform isn't as far fetched as it once seemed. It's actually a admission of what many in our community are already doing.

CDT Summit Report: No git for us, not yet

We had a pretty good discussion about using git for managing the CDT source. For the community members that care, git is critical to the future success of CDT. git allows the workflows we need to allow adopters to make local changes as necessary and then deliver those changes to the CDT project as candidates for inclusion upstream. That workflow is very difficult with CVS since it requires you to set up a disjoint repository. Bleach.

So we're pretty eager. However, at the end of the session, I got the feeling that we just weren't ready for it. At least not yet.

First of all, there's just the need to figure out all the workflows we want to support. I was excited at the beginning of the summer about using Gerrit code review for CDT just like the egit guys are doing. Having a system to manage code changes, to make them visible to all, and to make it easy to do code reviews, is very compelling. However, it turns out that the egit use of Gerrit was a trial and the Foundation staff isn't ready to support it yet.

So we need to go back to square one, managing patches in Bugzilla which takes away from that fork and contribute workflow that's bringing us to git to begin with. It does bring up the need to produce some documentation so that we can decide how we want to work and to educate the contributors on that.

That brought us to the egit plug-ins. There has been some really good progress with egit thanks to the team working on it. I'm using egit for a number of projects I'm working with, both Java and C++ and am really liking the experience. However there are still a few things lacking and defects that I'll be raising bugs on. I am seeing a lot of exceptions when doing merges, including out of memory. I want to be able to compare branches, but I guess that's what the Synchronization view is trying to do. But then the usability of the Sync View is very confusing.

And finally, the real show stopper for me is the lack of being able to create patches between two commits, e.g. between two branches. Again, our big workflow is to allow adopters to fork and contribute the results back to the project. They will be creating local branches and committing updates to them. So being able to create a patch between their branch and our master is a must.

At the end of the day, we're just not ready. Once we figure out how we want to work with git, and when egit fully supports those workflows, we'll jump on the bandwagon with both feet. Until then, we have work to do.

A great CDT Summit 2010

After a year off due to lack of travel budgets, we held the CDT Summit again this week this time at the Ericsson offices in Montreal. It was a great summit and proves again why we do these things. Many times I looked up during the meetings and then through the evening events and saw people from different places talking to eachother, laughing, sharing stories and experiences. You hold these things to have technical discussions on the issues of the day and plans for tomorrow, but the real value is the relationships we build working together face to face. You just can't duplicate that on-line.

Many thanks to our hosts at Ericsson, Marc Khouzam and Dominique Toupin who worked tirelessly in the weeks leading up to the summit and fought through all the infrastructure issues you end up running into during these things. It all worked out superbly in the end, despite our ribbing them about it :). Thanks guys!

Also thank you to our sponsors from Ericsson, Eclipse Foundation, Wind River, Texas Instruments, Mentor Graphics and Google whose financial contributions made this all possible. We had a very special event on the first night and got a sense of the history of Montreal and a party in a unique setting. Not to mention the superb meals we had for lunches and breakfast, to fuel our efforts during the summit. It really made us comfortable and let us focus on the work at hand.

I have a lot to write about on the topics we discussed. There was a wide variety and some of these things will be of interest to the general Eclipse community as we work to make the Eclipse the best IDE for C/C++ developers in the industry, which is not always an easy task given the general nature of Eclipse. But I'll blog about those things over the next few days.

My biggest thanks go to the 30+ people and their employers/sponsors who allowed them to travel and take the time out to contribute to the CDT summit and to the handful of people who attended remotely through my CDT conference bridge and Webex account. These summits are most successful when the people come with the mind of working with the rest of the community to do something greater than they can do on their own. As I mentioned to James on his way out. It's why we do open source: "to have some fun and to change the world".

More later...

Entering the Realm of Interaction Design

I'm about to embark on a relatively new era in my career. I'm always looking for new challenges and there is a huge need with the tools I work on to improve their usability. UI design is a long way from C++ parser writing, but I've seen great UIs and I know pretty quickly what a bad one looks like. And I want to make the life easier for my users.

I was given a book written by Alan Cooper called, "The Inmates are Running the Asylum". I only read the first couple of chapters but it really chimed with something I always had in the back of my mind. Computer programs are usually written by engineers that assume (or don't even consider) that users think the same way they do. And Cooper has some pretty good and common examples of where that assumption ends up being pretty embarrassing. Or worse, "it leaves the user feeling pretty stupid."

When you work on a UI feature, often you're following the Model-View-Controller paradigm. Being a computer person, you start with the model and then think of ways of showing that model to the user and then controls for manipulating the model. You want to make sure they can change everything to get the most out of the fine work you're doing.

Well, the user doesn't care squat about your model. He has a job to do. He is trying to accomplish some goal in order to look good in front of his customer. And he needs to do it quickly so he can get home to see his kids before they go to bed. He doesn't have the time to learn the intricacies of your model and the esoteric ways you've provided to view and control that model.

Cooper suggests we need to do Interaction Design as a lead up to the actual code. Understand what the user is trying to do and find ways to allow him to understand your software quickly and to get his job done quickly. Design the View and Controller first, then worry about the model. Get under the user's skin, know what he knows, feel what he feels. That's a pretty tough thing to do for us engineers who love the challenge of creating the world's best algorithms. You don't need to empathize with anyone to write "good" code.

It's a hard job to put together an intuitive interaction design that accomplishes what the user needs with minimal gestures, but I look forward to that challenge.

Hypervisors drive Heterogeneity

I have put together a pretty neat little lab here under my desk. As I always say, you have to use the tools to understand the needs of the users. You have to get into their shoes and see what you like and don't like. Then you have a good chance of building tools they'll actually use and like.

My lab includes two "embedded" systems on the right. The top is a board that has a Freescale PowerPC P4080 8-core chip in it. I have attached my Wind River ICE JTAG unit to it to test some really heavy duty multi-core scenarios. On the bottom right, I have what looks like a basic PC, and it is, but it runs Wind River's hypervisor hosting three operating systems: Wind River Linux, vxWorks, and of all things Windows. I don't have the P4080 system booted up yet, but my intention is to run the Hypervisor there too with random combinations of wrLinux and vxWorks.

As I put this together, it really drove home the need for an IDE platform that is heterogeneous. That's a hard word to pronounce, but what I really mean is an IDE that can target any operating system that can run in a hypervisor configuration, which is pretty much all of them. And that means an IDE that has plug and play support that lets you create the source for applications that can run on them all, build that source for any and all of the target platforms, and debug the application as it runs on one ore more of them.

And, you guessed it, the Eclipse CDT C/C++ IDE is a great platform to do that with. We have build and debug support for the GNU toolchain for Linux and from Wind River we have commercial support for vxWorks and Wind River Linux, and upcoming in the next release of CDT, we'll have support for Microsoft's Windows SDK which includes Visual C++.

As well, I'm about to embark on a very interesting journey with the Target Communication Framework as we advance it's debug capabilities to cover all of these platforms as well. With a common framework for agents that run in all these environments, we'll have the ability to plug 'n play capabilities into these agents and come up with tooling we haven't even dared to consider before. Am I pumped about it? You betcha. We've long had the advantage of plug-in architectures with our Eclipse-based tooling, and now we'll get that advantage all the way down to the target as well.

And it's really these hypervisor scenarios that have brought me here. It's finally a concrete example where you really need the heterogeneous capabilities that have driven my work on the CDT. And, it's something to sell our employers with too :).

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?

Exploring Game Development with CDT

Well, it's holiday time. I'm off this week and next and it's filled up with a family union my wife and I are hosting, but I am stealing away some time now and then and my hobby time going forward with one of my dreams, building a game engine.

Of course, it's impossible to build a game engine yourself. So instead I am putting together a number of open source pieces and integrating them. The amount of code I need to write should be pretty small but should be significant enough to help me get some real world experience using CDT. The best way to get into the mind of some one who uses your tools and understand their needs is to actually be one for a while.

The key part of the CDT angle is multi-target development. The plug-in nature of Eclipse and CDT's support for tool chains allows it to be used to write applications for multiple platforms. In this case I'm going to do a mix of desktop and mobile featuring Windows and Linux on the desktop side and Android and eventually MeeGo on the mobile side. Android and MeeGo are particularly interesting in that I firmly believe these platforms could eventually find their way onto desktops one day. So writing a game that targets them and Windows and regular Linux desktop isn't really that much of a stretch. (BTW, yes, I'm purposely leaving out Apple for fear of getting trapped in the "walled garden").

For the engine components, I'm using the OGRE 3D rendering engine that is currently being ported to Android already (very cool to see). It uses freetype for fonts for displaying text and freeimage for loading images. I'll use bullet physics for the physics engine. There doesn't seem to be a common audio package so this may be custom per target with my own API over top. The same may be true for input, although the OGRE samples use OIS but that would need to be ported to Android.

The final piece of the puzzle will be the blender 3d editor which is going through a re-architecture right now and is extensible using python. Create your content using blender, export it with the help of python scripts and load it up into the game engine on all four platforms. Sounds like a dream that only the pros can pull off.

We'll see how far I get. But I benefit from it in two ways - living that dream, and getting some real life experience using Eclipse for serious application development that should lead to some ideas on making it better and maybe I'll come up with ideas for new tools. Sounds like a win-win.

I'm not anti-e4, I'm just busy with other things

As we start the discussion about CDT and e4 on the cdt-dev list, I just want to make sure people are clear when I make statements that appear anti-e4 that I'm not anti-e4. If you like e4 and you want to use it in your project, go for it. There's some really cool things there and the guys are doing a great job of pulling it together.

But I have other important problems to solve higher up the stack than I see e4 trying to solve. In CDT-land, our biggest issue is getting people to even use Eclipse who are using emacs or vi and gdb just fine and who struggle adapting to the world of IDEs. We need to focus on enhancing the value of Eclipse and simplifying adoption to make it more appealing for these people to buy into our wares.

At the top of our list are some workflow issues and the flexible resources work that started in e4 but moved in to 3.x is a start on that. I think we still need some work on build to support multiple build configurations per project, and for build to work just as it does from the command-line. And the launch UI is over complicated for what our users need. But those things are all the platform stuff we really need. And we do have people trying to make contributions in those areas.

And, we have some things to work out in our own kitchen. We need to fix up the CDT build system so that vendors aren't so frustrated by it that they end up writing their own. Then there's the world of debug and systems analysis where I think we really need some innovative UI approaches. As starters, I don't think you can visualize a massive multi-core system using a 2 dimensional UI that assumes a single context. I'd love to see something like Clutter in SWT.

So while the world is rushing towards HTML5 and the cloud, that's great and everything, but we still have a lot of work to do to make Eclipse a great IDE on the engineer's desktop.

My own little PluginFest

This is a bit of a follow up to a blog entry done by my product manager partner in crime here at Wind River, Emeka. I spent a couple of weeks recently (in the middle of the Helios rush too) to put together a demo he is giving today at IBM's Innovate Conference. It was great because it reminded us of what we're really trying to do here creating IDEs using Eclipse, *Integrating* tools.

The the code in the demo is quite small but that's a good thing thanks to good APIs. It's a menu item associated with the editor for Wind River Workbench's Memory Analysis database. The item takes that database and zips it up and attaches it to a newly created Work Item from IBM's Rational Team Concert, i.e. Jazz, product. The story goes that you see a problem in the memory analysis and you want to record it for someone to look at later. And that person takes the attached zip and opens it up in the editor to start his investigation, using the other information recorded in the work item and documenting his findings there as well.

The value of the integration becomes greater than the combined value of tools that Wind River and IBM have built on their own. And that's the promise of Eclipse and it was great to see that promise in action. But it also brought home that we don't see that happening enough. As we solidify the platform and the first layer of tooling, we need to keep driving the solutions and build up a bigger and better stack and sell our collective customers on the value of Eclipse and the solutions we're building for them.

A few years ago we held a PluginFest where we brought together a number of embedded tooling vendors and tried to plug and play their products. In the end, it was more to test that they co-existed with each other than anything. A few had real integrations to show. But I think we fell short of the goal and dropped the ball on the potential. Maybe it's time to bring us back together, not to test interoperability, but to explore opportunities to build real value add integrations that we can work on together. Emeka and I and the IBM RTC gang have started down that path. Hopefully it can be used as an example of the real value of Eclipse as an IDE and rejuvenate the ecosystem a bit.

Writing Games for Android ... and other app stores.

Tools is my passion, especially tools for native programming. Being a game developer wannabe, I'm especially excited when I see game developers using the tools I help build. And that's one reason why I'm closely following and helping out with tooling for the Android Native Development Kit. There's a great community there that could really benefit from a good CDT integration, and maybe who will come help make that integration great.

At any rate, I watched Chris Pruett's session on Android game development from Google I/O and found it very educational. The first half was about technical details and tips behind Android game development, but the second half was just about good game development for mobile platforms. It's a great view and I've embedded it at the end of this post.

The real game changer (sorry to use the pun :) in my mind is the growth of app stores or markets. Pretty much every mobile platform vendor is creating some sort of one stop shopping experience for their devices and it's a great vehicle for app developers to quickly get their wares into the hands of paying customers. And with systems like Valve's Steam, you also get this great experience on your desktops and laptops.

The biggest advantage of markets, as Chris illustrated, is that it's also a great way to keep in touch with your customers. Customers tend to be brutally honest about what you've provided them, and it's good to get first hand looks at that feedback. And also, thanks to the markets, it's also easy to get updates and fixes into their hands. It's a win/win.

Anyway, it's a great view. Take a look.

Update: The embed didn't work very well. Just click this link instead.

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.

Don't guilt contributions, enable them

This is a bit of a response to Dave Carver's post versus Alex Blewitt's and a bit of a topic I've dealt with mentoring projects, and how I operate on the CDT project.

Over my years in open source, I've seen time and time again where people on projects try to find ways of getting others to come help. A common one is to beg or guilt people into contributing. "You don't like how that works, then come fix it." That's easy to say. But I've seen that piss people off way more often than it works, and it only works in rare occasions. I think you need to be sensitive to the skill set and the ability for people to come fix it. Not everyone who uses Eclipse knows how to build plug-ins for it, or has the time to do it. Do you expect them to give up their family hours to come help you out? I sure hope not.

No, my preferred approach is to create an environment where contributions are naturally welcomed. Where those who do have the skills and the time can easily and quickly fix the things that are bugging your community. Creating such an environment isn't easy and it comes down to a number of factors. Probably the biggest one is to make everyone feel a part of the team. Everyone's opinion matters. And every contribution is treated like gold, whether accepted or not.

And Alex's story is very disturbing to me. I'd rather he write about how well he and the rest of the Eclipse team have gotten Eclipse to work on the Mac.

We need a JNI helper plugin

Now that I'm back being an engineer/architect, I'm again thinking of too many projects that I want to do with the time I have. I'm getting involved in the Target Communication Framework (TCF) which has an exciting opportunity to standardize target (in this case mainly embedded targets) communication and services for the purposes of debug and data collection amongst other things.

I am also trying to make it easier to use CDT for specific platforms. Windows and Android and soon Qt are the main ones there. But I've run into problems with the complexity of CDT's build system that I need work with the community to clean up.

And there is another shiny object has caught my attention and I'd love to get time on that too. Our long term holy grail on the CDT has been to support developing native libraries for Java. The debug scenarios are scary, but I've been thinking of another area that should be a lot more attainable.

That's automating the creation of the code that JNI development requires. There's two paths. One is generating skeletal C code for Java native methods. And the other is generating wrapper Java classes for C++ classes. There used to be commercial products that did that, but I'm not sure if they're still around. And given the power of the Java and C++ parsers we have in Eclipse, and the code generation frameworks available, it shouldn't be that hard, you would think.

I think this would be a huge benefit to JNI developers, or at least me :). The interesting thing to note is that Android had the foresight to use JNI for their native interface so there's a new community who could use it. If anyone is interested in doing something like this, give me or the cdt-dev list a ping.