Doug on the Eclipse CDT

Change, sometimes it just happens.

2012-01-31T00:43:00.002Z

Well, it's been almost two weeks since my previous employer decided it was time for me to make a career change. Of course there's more to it than that but that's all I'm going to say about that. "It is what it is," and I'm actually pretty excited to see where my career takes me next.

While I'm an independent developer (which sounds much better than unemployed, no?), I have a few things I want to work on. Writing again in this blog is definitely one of them. It's been way too long and I've gotten used to spewing things in Twitter which is very handy but doesn't stay around long enough and isn't long enough to capture my thoughts in time. I have lots of opinions on things and it's good therapy for me to write them down.

The main technical area I continue to be very interested is, of course, Eclipse and the CDT. I've spent a lot of time over the last few months learning and thinking about usability and the importance of design and user experience. Pretending to be a newbie CDT user and walking through normal day-to-day activities shows me a few areas that need to be addressed. And since I'm still a CDT committer, I have the power to fix them.

I continue to be fixated with mobile and the new world that mobile UI and application architectures brings us. There's a reason these devices are flying off the shelves at your local phone and electronic store. They're so easy for the regular consumers to learn and use, and so powerful. It's that kind of user experience I'd like to see brought over to the desktop as well. I continue to follow the progress of Qt 5, which I believe can be a great framework not just for new desktop paradigms, but for mobile as well. It still seems to have a ways to go before it's stable, but I'm going to start experimenting with it as soon as I can get a build that works on my laptop.

The third area is a new one for me that I started chewing on in my spare time over the last few months, and that's web app development. Node.js has caught my eye as it has with numerous other developers. It's asynchronous programming model is very similar to the way we often program in embedded to produce scalable systems that react to events in the real world. While JavaScript is the cool thing in the web world these days, I have wondered whether we could provide similar APIs in a type-safe world, say using Java. People use Java on servers, no? And the convergence of server-side apps and mobile clients and embedded devices is a natural. It's the "Internet of Things".

So stay tuned for more over the upcoming days. As I mentioned, writing is good therapy, whether it be text in a blog or code in the exciting new world of mobile/web.

Happy New Year, Out with the Old One.

2012-01-02T19:49:00.001Z

Surprise! I haven't blogged in a long time (except for the blurbs about the EclipseCon 2012 program, which has turned out great, BTW). There's probably a few good reasons why I haven't spent much time here. The main one, I guess, to quote poor Flyers goaltender Ilya Bryzgalov, I've been a bit "lost in the woods" myself. But like him, that's more a state of mind than fact. And for 2012, I see a few paths that will lead me out of this cloud (or into one which would be one of the paths :).

We lost a lot of great people last year. I'm not sure if it's just my perception because of what happened in my life, but it seems more than usual. For me, it was the loss of my Dad to cancer after a year long battle. He inspired me to live my life with honour and respect for everyone, something which I try to do a lot in my work as the CDT project lead. Communities built based on respect and openness to all comers is the key to success.

Of course, there was Steve Jobs. My wife got me his biography for Christmas and I finished it a couple of days ago. The parallels in his physical condition with my Dad's was amazing. While Steve waited too long to get treatment, my Dad waited too long to get diagnosed and both ended up with their cancer metastasized to their livers which brought about their end. Dad was pretty weak at the end, couldn't eat due to the morphine, but he made one last trip to my dear cousin's wedding where everyone got to see him one last time. Steve was the same and had his last trip to resign as Apple's CEO and had a nice chance to say goodbye. All in all, it's a lesson to take care of yourselves. Treatments are getting pretty good but you got to catch it and act early.

As for Jobs' life and times, I'll dedicate a whole blog article on that. Reading the book was pretty eye opening. I learned a lot about how he really operated and the true reason for his success. And I also got a look into the history and life in Silicon Valley which you don't learn much out here in the wilderness other than the occasional visit. One thing is for sure, I'm pretty sure that life has passed me by and I only regret it a little :).

There were other famous people that passed. Dennis Ritchie being the foremost for me. He doesn't get enough credit for the changes he brought to our industry. Yes, he invented C and helped create Unix, but more importantly, those technologies let average programmers in on the action. Unix machines have always been everywhere and accessible and with their built-in C compiler, you just needed an account to join in on the fun. It's where most of my generation started and why I'm so passionate about the CDT and enabling new generations to learn how to play with fire.

Well, let's stop there for now. I have a lot more to write about and have a new found energy to write about it. I'm hoping this year will be a much better year for me and a great year for you all. Expect to see more in this spot than you have in a long time.

:D

EclipseCon 2012 Early Bird and Looming Deadline

2011-11-16T17:04:00.000Z

We've had a really good first round of submissions and I have to admit I was overwhelmed by the number that we received. It was awesome and thanks to those who've already submitted. Of course there's always need for more and you have until Friday night to get them in. There are still a few gaps that need to be filled, like tutorials, and we're always interested in new things we haven't thought about.

To highlight the kind of talks we like, we've selected 5 early bird sessions. We're big on technical talks since that's what we hear you want to see most. We're also very interested in talks that help us think about our community and ways of working better with them and achieving growth. Here's the golden five. Only a hundred or so more to go :).

OSGi on Rails - a cool look at how the Eclipse run-times are being used with the Swiss railways.
The Eclipse 4 Application Platform Explained - an important talk from Tom Schindl on everything you need to know to build Eclipse 4 apps.
Xtext Success Story at Google - a case study on how Xtext is being used for good at Google.
Language Tooling in Orion - a look at the current state of tooling in Eclipse's development platform on the web.
Assholes are killing your project - an important look at how personalities can affect the health of your community and what to do about it.

We're looking forward to additional great talks we'll see in the submission system. Get yours in today!

EclipseCon 2012 - Submit Now!

2011-11-09T15:29:00.002Z

Sounds like EclipseCon Europe was a huge success again. The feedback I have is that the sessions were very well received. We really have a good formula to follow and it's so important to the success of a conference that the community jumps on board and helps out by putting together some great sessions filled with information and anecdotes that the stick with the attendees as they head back to their workplaces. Aside from the camaraderie of being all together in one place, it's the sessions you remember most.

Now it's time to look ahead to EclipseCon 2012 to be held in Reston, Virginia in the Washington D.C. area from March 26-29'th. The program committee and I have had a number of meetings over the last few months and we're ready to go. It's going to be a lot of work going through all the great submissions I know the community is planning and it's going to be tough to make the best decisions. But we have plenty of past experience and community leaders on the committee and I'm confident it'll be good.

Please take note of the deadlines as they are fast approaching. The original deadline of November 11 is still there to help us select a small number of early bird sessions. These talks always get a little extra special attention so don't delay in getting your proposals in. Also the earlier you get your proposals in, the more time the program committee has to look at them. We are already forming opinions as the submissions role in. And don't forget the final deadline is November 18. Our task master Ian ;) is pushing us really hard to get a program selected by December 1, so there's no room for delay.

Submit yours today at http://eclipsecon.org

EclipseCon 2012 - We Need You!

2011-10-20T14:46:00.000+01:00

Everyone sounds excited about the upcoming EclipseCon Europe 2011. Having been to a few of them, I can confidently say you guys are going to have an awesome time. EclipseCon, whether it's in North America or Europe, is always a great event. It's great because of the people. Because of the community and comradery that we all share whether we're in the sessions, in the halls, or in the bar :). It's a great opportunity to show off what we've been working on, to help those who want to learn more, and to help grow the community.

So while you're packing for EclipseCon Europe, I'd love it if you gave some thought towards EclipseCon North America 2012 next March in a cool new location. The submission deadline is a fast approaching November 11. The success of each EclipseCon leans so heavily on the quality of program. And with such talented people in our community, I know we can put a super program together. But we need your help.

Please think of a great talk or tutorial topic and head over to the submission system and put it in. The earlier you get it in, the more time the Program Committee can spend with it and offer advice to fine tune it for our audience and make sure it's the best it can be. Take your opportunity to help make EclipseCon North America 2012 the best it can be too.

http://www.eclipsecon.org/2012/program/sessions/proposed

Honoured to be your EclipseCon 2012 Program Chair.
Doug.

A Reprint for Steve Jobs

2011-10-06T14:55:00.000+01:00

I wrote this back in March after being totally inspired by Steve Job's iPad 2 keynote. The passion in his voice led me to believe this was to be his last message to us and he really wanted us to understand what he was trying to say. And in the end I was right. I will never forget those words and I was going to write about them again, but what I wrote back then says is about as good as I can ever do now. Rest in peace, Steve, and we will all try to keep your legacy alive.

___________

As a senior software engineer wondering how the hell does Apple make such great products, if you do anything, listen to the last five minutes of Steve Jobs' keynote introducing the iPad 2. It opened my eyes and made me a believer. Here's what he had to say:

"It's in Apple's DNA that technology alone is not enough. That it's technology married with liberal arts, married with the humanities that yields us the result that makes our hearts sing. And nowhere is that more true than in these post-PC devices. These devices need to be more intuitive than a PC where the software and the hardware and the applications need to intertwine in a more seamless way than they do on a PC. And we think we're on the right track with this. We think we have the right architecture not just in silicon but in the organization to build these kinds of products".

It's the passion with which he said it, and the proof in the products that Apple continues to deliver, that have won over an army of fanboys, that proves he indeed does have the right formula. Technology built for humans, what an incredibly simple yet unappreciated idea by so many in our industry. Sure we have the odd usability expert sprinkled through our organizations, but to have an organization and culture and passion built around these ideas? What magic we could make.

The good news is that I don't think Apple has a patent on these ideas. If they do, I quit now. But I don't think so. Is it possible for a techie to understand what needs to be done? I have my doubts. Techies are an odd sort. We've all seen it. The uber-geek who writes a killer algorithm to make products sing. But he needs help. He needs that special someone to show him how to take that algorithm and produce something regular people will fall in love with. The path is there, and we see it in everything that Apple makes, it works. But don't let them have a monopoly on it.

A UI Revolution is Coming. Are we Ready?

2011-06-21T02:20:00.000+01:00

This topic has been brewing in my mind, and in this blog, an in my tweets for months now. And one final event made me certain it is going to happen. And that event was the introduction of Windows 8. Not that Windows 8 is really that big a deal. But it confirms for me a trend that's going to change the way we interact with the desktop applications we use daily, including Eclipse. Yes, a UI Revolution is coming. And we need to make sure we're ready, or Eclipse is going to look old very quickly.

What am I talking about? Well, let's start at the beginning. There is no question that Apple started the revolution with the iPhone and iPod Touch. Yes, there's an app for that. There's an app for everything. Apps are small, easy to create with a simple UI that was intuitive even for "regular" people (and, no, computer people aren't very regular). The rest of the world outside the walled garden got their fix thanks to Android and Windows Phone and a few others. Smartphones have revolutionized how we think of applications.

Of course, once we have smartphones figured out you want to see if the same ideas scale upwards. The next big hole to fill was tablets. Tablets have been around for a long time albeit with the old UI borrowed from the desktop. It didn't work. But could the smartphone UI scale up to tablet sizes. Indeed. iPad is gigantically successful and Android and Playbook are following behind. We've finally figured out how to make tablets commercially successful by using UI that again was intuitive for everyone.

Now, as I've been wondering here and there, what about the desktop? Does it make sense to bring these same principles to machines with larger and multiple screens with keyboards and mice and fast CPUs and GPUs? Well, I think we hit a tipping point. And that point happened when someone got the bright idea to slap a keyboard and trackpad onto a tablet, i.e., the Asus Eee Pad Transformer. Watching the videos people have posted onto YouTube of the Transformer in action, I am convinced that a tablet UI would work just fine on a desktop platform.

And apparently, so is Microsoft, which brings us back to Windows 8. Early videos of it show off exactly that. It's the Windows Phone 7 UI, scaled up for both tablets and the desktop. And I think it looks pretty sharp. And I don't see any reason why Android couldn't do the same. And with the work Nokia/Trolltech are doing with Qt version 5, I can see how we can do the same for Linux. We all love the usability of our mobile devices, I want to love my desktop just as much.

But there's problem. Watch the Windows 8 demo when they bring up Excel. It's revolting, but in the wrong direction. You finally see how bad the old time UI that we've had for decades and that has been replicated on every desktop OS we know really is. We really need to invest in upgrading the UI and potentially reinventing those applications if we want to keep them around.

And, yeah, that includes Eclipse. Unfortunately, the old technique of putting a common API over the native UI frameworks isn't going to work. The new frameworks are just too different. And making them common looses the gains they bring individually. We got away with it before because they used to be so similar. Not any more.

So what are we going to do? There's many ways, I suppose. The itemis guys gave a great presentation at EclipseCon on one of the strategies they used. They use a DSL that implements the logic and general layout and generate code for each of the UI frameworks they support. It was cool but I'm not sure how complex of an app you can build that way.

But I do think they are on to something. You need to program the UI in the language and technique that the framework supports. But the core logic of the application should be able to stay the same. You know, Model-View-Controller, and you only need to swap out the View part? And we should be set up for that, no? Isn't that why we broke things up into ui and core plug-ins? Or do we have so much logic in the ui plug-ins that this won't work?

So this is an area I'm going to try and prototype. And I'll start with Qt5 with their QML Javascript-ish UI language and see whether I can hook up Eclipse services through some sort of QObject C++ to Java bridge and make them dance. I have a feeling it's going to be a dismal failure. But you have to start somewhere. Doing nothing doesn't leave me feeling very comfortable about Eclipse's future after the revolution.

Build for All

2011-06-15T02:41:00.001+01:00

OK, when a thought spreads out more than two tweets, it's time to write a blog entry instead. Ed Merks tweeted from the Eclipse board meeting (I presume) about the board's concern that if Kim Moir got hit by a bus, we'd all be screwed, or something to that affect. And it's true. Kim is a most valuable person at release time for getting the Eclipse train out the door. Without her for the Eclipse Platform, or David for the p2 site aggregation, or Markus for the EPP builds, we'd be scrambling.

So while I don't want to take anything away from the great work they do, I do think it's time to move to a better system where anyone can easily jump into their shoes. Not only that, but I'd like it to be easy for anyone to be able to checkout all the Eclipse projects they need and build their own product from it. I often get questions on the recommended approach to do such a thing and I don't have an easy answer for them.

But there are two technologies that we are currently deploying that can improve the situation immensely. And I am working on bringing both to the CDT. The first is git and the second is Maven with the help of the Tycho plugins. As an example, I'd like to checkout all the source that feeds into the Eclipse C/C++ IDE package and then from the root directory, type 'mvn clean install' and have the zip file come out at the end.

Better yet, I'd like to clone all the source, commit any bug in any of that source on a branch, and do a build to get a test package, or a package I can send to my downstream customers. That scenario happens all the time in open source and git is making it a lot easier to manage your local branch, while making it easier to push changes upstream. And Maven/Tycho can make it easier to send builds downstream.

But it only really works if all Eclipse projects buy in. Maven can be done in parallel with whatever build system they are using so that's not a huge problem. Getting them all to move to git is a bigger challenge. But I see the momentum starting, especially with the Eclipse Platform project discussing moving. So I'm confident we can get there. We just need to show the value the community gets from the significant work that is required to make these changes. And then we can leverage that good work ourselves and build the EPPs at eclipse.org using the same technology.

Hope Returns for Linux Desktop

2011-05-23T23:10:00.005+01:00

So you may be wondering why I care so much about finding the next generation desktop UI. I have expressed here my hope for Android and whether it works to bring the advances made in tablet UI design to the desktop. I have also expressed my dismay at how ugly, i.e. low usability, that the Linux desktop brings today. Windows 7 is fine but the underlying OS is not very good for developers needing the great tools that *nix brings. And that brings us to Mac.

Many have noticed how often you see developers using Macs. It seems to be the standard platform for the Android devs at Google. Many Eclipse developers are using them as evidenced by number of Apple logos on laptop lids you see looking out to the crowds at EclipseCon. The Mac seems to bring the best of both worlds to the developer, a great UI along with a powerful Unix operating system underneath.

But I have one problem with that. My employer won't buy me a Mac, not many do. And I'm not willing to pay my own money to enter into the walled garden. My family is happy with their Windows PCs. It's what they're used to, and it runs the games they play. And I have more important things to spend money on.

So it all seemed like doom. The alternatives just weren't there and my hopes seemed more like dreams. But something's changed. Android does seem to be getting closer to the desktop as evidenced by the new tablet/netbook convertibles that are out and coming down the pipe. But the thing that has me excited actually is two advances in the last few months with Linux.

One, the Wayland display server seems to be gaining momentum. Or at least I've managed to build it and have seen it running. It throws away X, the bane of the Linux desktop experience, and replaces it with an OpenGL compositor. I expect that momentum to accelerate thanks to the second advance. And that is Qt 5 and it's declaration of Wayland as one of it's key target platforms. Combine that with graphics acceleration that becomes the heart of the Qt 5 architecture, I think the possibility now exists for a Linux desktop that looks as great as Mac and with the same *nix underpinnings. Perfect.

And with Qt's use of declarative UI with JavaScript underpinnings, called QML, it should be easy to build a complete desktop environment. No Gnome. No KDE. Something new that gives us a new level of usability. My dreams are turning back into hope. Linux may just have it's day yet. And developers will benefit.

Update: That reminds me, I think the Eclipse front end should be replaced with Qt 5. It runs everywhere Eclipse does. Now that would be something...

Qt 5 #ftw

2011-05-09T21:44:00.000+01:00

I just finished reading Lars Knoll's blog and his whitepaper on Qt 5, the next major version of Qt. I don't think their plans can get any better. I am an instant fan.

They are planning on making it a true open source project "from day 1." This is critical to the future success of Qt 5, especially given all the questions over Nokia's future direction with Qt. While it helps with the trust factor, it's also a great move by Nokia who are showing they are concerned for Qt's future and community.

The most exciting stuff though is technical. They recognize that user interfaces are going through dramatic change. And that hardware accelerated graphics is at the root of that change. People want to manipulate objects in their applications, not stare at static widgets. As I mentioned to a colleague the other day, people want their user interfaces to be real, for the objects to have realistic physical properties, to have weight. With the architectural changes they are planning for Qt 5, it'll be a lot easier to build such interfaces.

There's also the recognition that people don't want to write reams of code to make these interfaces happen. Qt will bring their markup language, QML, front and center to the developer. JavaScript, using Google's V8 engine, will be the secondary programming language. C++ will still be available but you only need to use it where you need to use it. Again, all this is focused on making applications easier to build.

One of the key advantages of Qt has been multi-platform support. With the focus on using scenegraph's as the key composition mechanism, the requirements on the host windowing system is reduced greatly. And with their new Lighthouse architecture, porting will be even easier. And what that should lead to is the quick arrival of ports to Android and iOS, bridging the gap between the desktop and mobile device like no one else has. And with Wayland given prominence as one of the primary supported platforms, my hopes for a revamped Linux desktop are given a lifeline.

I'm pretty pumped about this news (obviously). And I'm excited for the future of computing devices with truly usable UIs. But seeing this news, along with watching demos of Apple's new tablet apps (especially Garageband), Android's Honeycomb, RIM's Playbook with the TAT interface, Eclipse's UI all of a sudden looks very old. I'm not sure if Eclipse 4.x gets us any closer to this level, but I'll be very curious to see how we can bridge Eclipse onto the new Qt 5. This is where I fear for the future of Eclipse.

Eclipse on Android, or Android-like usability for Linux?

2011-04-22T03:58:00.000+01:00

If you follow my blogs and my tweets, you know me as an Android fan boy. There are a number of reasons why but the main ones are that it provides a huge leap in usability and I can build from source myself and get it running on any device I want. And that includes x86 PCs, some provided by AOSP itself and a lot from the valiant effort put on by the android-x86 gang. And now having seen live action videos of the ASUS Eee Pad Transformer, the Android tablet that transforms into a netbook, I am even more convinced how cool it would be to have Android as my PC environment.

But, there's a problem. The applications I use, and that of course includes Eclipse, don't run on Android. I also spend a lot of time doing embedded system platform builds and the Android user-space is missing almost every utility I would need, including the gnu compilers. Now nothing technical prevents these things from being ported over to Android as it is built on a Linux/FreeBSD inspired base and you could probably work around the few twists that come with it. And I do know a few people that would love to see Eclipse running on these Android netbook type devices. And maybe there is a future in that.

On the other hand, I have everything I want on Linux. But I find the usability horrible. I've had a chance to play with GNOME 3 with Fedora 15 and it is a big improvement, but I fear we'll be living a long time with the legacy GTK-based tools which are really getting out-dated. Even Qt comes with it's own set of issues.

I blame it all on X in the end. It probably doesn't deserve it, but I've been an X user ever since I built X11R2 myself 20+ years ago. It's old and it's done. The new effort behind the Wayland display server provides a much better architecture IMHO. It gets rid of all the X legacy and builds directly on top of EGL and OpenGL ES. That should give us the flexibility to do some really good things with usability with the help of accelerated graphics hardware and physics engines. That's what Android Honeycomb does, and there's no reason why we couldn't provide an equivalent environment for Linux. It's just a matter of someone driving the vision in that direction.

And who knows. Once Wayland is in place, how much effort would it be to provide the Android run-time mixed in with the Linux user-space. The RIM guys have figured that out with the PlayBook and their Android support someone astutely coined FrankenBerry. Wayland could easily support a client that drew at the command of an Android app.

No matter how you slice it, it's a great time to be in the software business. The mobile guys are driving innovation in usability. Us desktop guys need to find a way to catch up.

The Rise of the User

2011-03-29T16:37:00.000+01:00

One thing is becoming more and more clear. Large companies that are users of Eclipse technologies are getting more and more involved directly in the building of those technologies. I've definitely seen this in the CDT space where probably about 1/3 of our committers are from companies like this.

One thing needs to be made clear, though. This is a gigantic shift in the tectonic plates that is the embedded software business. Supply chains are king and in the past companies relied solely on their suppliers to meet their needs and were held accountable for anything that went wrong.

With the advance of open source technologies in these companies, I'm convinced it requires a change in strategy for the suppliers. Suppliers need to be more sensitive to the aspirations of their customers in open source. I'm not sure what that means and how they need to change their practices to accommodate this change in the industry. But those that don't change will be hurting somewhere down the road. It's an interesting and scary time all rolled into one.

Eclipse and the Post-PC Era PC

2011-03-23T16:38:00.000Z

The best thing about EclipseCon isn't the sessions, although all the ones I've been to so far have be great and educational. It's not the receptions, although what a great way to get a feel for the energy around Eclipse. It's not the beer, sacrilege you say. It's those little conversations you get into with fellow Eclipse contributors about the craziness we could get into if we dare try.

Last night I was talking to an e4 committer to be unnamed to protect the (not quite) innocent. I was commenting that e4 really has piqued my interest with the performance and the promise of flexibility. But the one thing that really bugs me, and I mean really bugs me, is the editor area and how it looks so different from the editor area we have in 3.x and really sticks out like a sore thumb. He explained that it was intended to support the use case where you have two editors split in the area to do a file compare and you wanted to send them both into a shared full screen mode.

OK, I get that. But I do fear though for the poor new user who will see this and be really confused at look of it. He may not think immediately that there's a problem, but something will be latent bugging him that things just aren't quite right and he'll feel comfortable and uncertain about why things look the way they do. Not to mention the screen real estate it takes up.

At any rate, this blog isn't about that. It's about what I brought up next. I jumped into the rant I started with my last blog entry about the need for us to take very seriously that we are building this stuff for humans. We need to empathise with them, and as technologists, we aren't very good at that. It's just part of our nature. And it's worse when we actually think we are when we're not, and that's how we get so much crappy software out there in the industry. We need to build are software organizations and get into our DNA that it takes more than just great technology to make great products. We need to understand or get people who's job it is to understand humanity and what the humans who are are customers real needs are, especially the ones that they can't even express themselves.

And we all know by now that Apple and the rest of the tablet vendors (and I played with a live RIM Playbook yesterday and it's pretty hot) get this and have it in their DNA to get usability right. And I have a burning curiosity about what the world would be like if that effort also went towards fixing the usability on my laptop and what a "Post-PC Era PC" and particularly Android Honeycomb like the one that ASUS recently announced. They've managed to take their work from 4" smartphones to 10" tablets. Can they take it to my 15" laptop and my 24" desktop. I think, or at least hope, so.

And I pose the question, what would Eclipse look like on this device? What would Eclipse look like if it was an Android app that followed the look and feel of the other Android apps. We pondered that for a bit. There wasn't an overwhelming favourable response from the crowd that had gathered by that time. But I am very curious and hopefully we can at least understand what the tablet makers are trying to accomplish and help drive forward that kind of innovation in usability at Eclipse as well.

Understanding Apple's Greatness

2011-03-07T21:51:00.001Z

Mobile Platforms Rule, Next Stop Desktop

2011-02-11T16:14:00.000Z

What a crazy week in the mobile world. Android's tablet buzz continues to gain steam towards an imminent launch. Rumors of Apple's iPad 2 are starting to roll in. Rumors of RIM's BlackPad, uh, I mean PlayBook, running Android apps. Then some concrete announcements from HP on the rejuvenated webOS with some nice looking phones and tablet. And today the big Nokia/Microsoft Phone announcement. How does one keep up with it all while trying to do their day job :).

With all that's going on, it's pretty clear one thing in my mind. The rate of innovation in the mobile space is stunning. Why did it take these new platforms to unleash all this creativity. Why doesn't my desktop look as sexy as all these tablets? What a price we paid for platform certainty under Microsoft, the closed hardware ecosystem of Mac, and the lack of real investment into the usability of Linux. It's quite sad, really.

But I also sense opportunity. I've been closely following the progress of the android-x86.org project as they attempt to bring Android to x86 platforms, because I'm very curious about how the Android experience could scale to the traditional netbook, notebook, desktop. Frankly, it isn't very good. But with Honeycomb, and the focus on larger screens, I have hope that will change. We'll see when Honeycomb hits the AOSP.

And that thinking was somewhat validated by one of the most interesting announcements out of the HP event, at least in my mind. And that was the intention of HP to bring webOS into the PC space as well. Now all we got were words and almost no details, let alone a demo, but I am very curious about what they are going to come up with, and whether it will actually pan out or not (there was a sniff of vaporware in the air).

So we'll see where this all lands. I hope we find out soon as this thing is keeping me up at nights thinking of all the possibilities and how this will change app development. As I keep saying, it sure is a great time to be a software developer. The shackles of the past couple of decades have been released and innovation is rampant.

Coding from Workstation and PC to Tablet and Superphone?

2011-01-09T17:50:00.001Z

In the early days of my career as a software designer, standard fair was to have a workstation on your desk. These were pretty big machines specially built to get as much power as it could out of hardware that we had at the time. They were pretty expensive, but they were the only thing that could run the tools that we needed to run. HP and Sun where the big players there, with Sun's SPARCstations being the cat's meow.

Then a major shift happened. Desktop PCs, driven by consumer needs and economies of scale, got to be as fast as these machines at a fraction of the cost. Yeah, you had to deal with Windows NT, but the economics of it really left us with little choice. And that left very few people still using workstations and it pretty much killed that industry, or at least left it to small niches and conservative companies that still fear Windows.

In the last five years, you see laptops starting to eat away at the desktop. There's nothing more liberating than sitting on you couch coding up a storm while the hockey game is playing in the background. Lots of software developers are using laptops as their main machine, yours truly included. The desktop machine is now only needed when I have big builds to do that require fast disks and 8 threads of CPU. Mind you if I could get that in a laptop that doesn't set my pants on fire, I would.

So all along it seems, we've been following the consumer as they paved the way to cheap and powerful computing devices. And as we've seen at recent Apple events and last week's CES, it's pretty clear the consumer is heading somewhere new, to the ultra-mobile with superphones and tablets. The question is, can we software engineers follow?

I think in the past we were able to follow because there were always high end versions of the consumer devices that could meet our needs. And it left in place one very critical tool for the software guy, the keyboard. Until we stop coding in text, we can't give up our keyboards. But aside from that, I don't see the high end version of these devices that could do a massive build or run a big IDE like Eclipse. They really are a new class that I don't think will cut it, at least not on their own.

So where does this leave us? Well, one answer jumps to mind which I'm not sure I like yet. There's growing discussions about cloud computing and doing software development in the cloud. I've investigated it myself in the past and it is a very plausible future. Though, I'm not sure we're ready to sit for a 10 hour day typing code into a tablet or superphone but I can imagine there being some use to being ultra-mobile for the software developer and not being too far away from his code. Tools like Hudson would show just fine viewed from a web browser on a tablet or from a smartphone app (which already exists BTW).

It's going to take some time to figure out how to leverage these devices, but you can count on one thing. We're all gadget junkies and we'll figure it out somehow.

Is Backward Compatibility Futile?

2010-12-22T03:42:00.000Z

In the last few weeks I've run into two products that I'm working with that try to maintain backwards compatibility with previous Eclipse releases. That is, while working on an upcoming release they want to make sure their plug-ins work all they way back to Eclipse 3.4 (one case only to 3.5, but still).

And I understand the desire of that. I've found old plug-ins that I want to use which claim support for 3.5 say and I'm very happy when they install and run with 3.6. And I'm even happier when the install into and work with M4 of Indigo. It's a difficult decision to pull back from the latest and greatest to get some needed functionality. It doesn't seem right.

But for these products, one thing should get in the way of that, the CDT. We don't claim 100% API compatibility from year to year. There's a reason why we're working on CDT 8.0 while the platform is still 3.7. And there's lots of practical reasons behind that, the main one being that we don't want to be tied to bad decisions made in the previous release. The more external tools we try to integrate and new features and just general clean up, we need to make things better even if we have to change APIs to do it.

No it's not fair to the community, but then we really haven't had a lot of push back from the community to stop that behavior. We can only assume they're reasonably happy to follow along, releasing their plug-ins with a fixed line up of Platform and CDT. And maybe that's it. The CDT ecosystem isn't set up where vendors plug-in their CDT integrations into each other. We tend to be competitors at that level, not partners.

But I think that is going to change very soon. Of the two products I mentioned, one is more mature and I guess CDT just happens to be backwards compatible enough that things just work. I'm a bit surprised but it relies mainly on debug APIs which we've been pretty careful to preserve. But without guarantees, I fear what they are doing.

The other is new and I'm kinda getting in on the ground floor. I have to decide which version of CDT to support. The rest of the stack supports back to Eclipse 3.5 which would be CDT 6. But then I want to do something good with CDT scanner discovery to properly set up the indexer. There should be some nice fixes in the upcoming CDT 8 for that. So do I have two versions of this thing? That's kind of where it goes, which is why I'm hoping we get these APIs locked down soon, for the good of all integrators who are facing the same decisions.

A Switch in the Grassroots? to Mobile?

2010-12-08T06:26:00.000Z

It's no secret I'm an Android fanboy, of fanbois, or what have you. I'm not sure why. I guess what really sold me was the ability to run it in an emulator on my laptop before it was even available in phones. It was exactly what I was looking for in a mobile/embedded target so I could play there and learn what application developers need out of their IDE, or in my case, the CDT. Yes, iPhone was already out but I didn't have a Mac so Android sold it for me. If I had a Mac, who knows, maybe I'd be an iPhone fanboy with the rest of them.

As I mentioned in my last blog, I've been busy doing "real" work here at Wind River and now have finally got a chance to stick my head up and see what the CDT needs from me. My efforts in the CDT in recent years is all about getting the CDT into the hands of the grassroots of software developers, people who are hobbyists or students who are looking for a free IDE they can use on their projects. The commercial theory behind that is to make the CDT ubiquitous so that when we go to sell them our high value products based on the CDT, they have less of a learning curve and barrier to adopt those tools. Can't say whether that's been working or not, but there is no doubt that the CDT plays a major role in the embedded space where I work.

But, now, I am starting to wonder if my past focus on the grassroots needs to change. Previously, it was all about supporting Windows development with the CDT. Linux too, but that was generally taken care of without my help. The Wascana project was born out of that and with Helios it reached it's 1.0 version. You look at it, though, it only has 10,000 downloads which is actually half of the previous 0.9 version I released 2 years ago and that release had nowhere near the advertising I have tried to give Wascana 1.0, even with a prominent mention on CDT's download page. Maybe the grassroots has switched. And I think I know where I need to focus next.

I don't know if you've been following the geek news but Android 2.3 was released yesterday. As @sogrady correctly pointed out, there's not much exciting there, at least not for the consumer. But if you're an Android app developer, especially one who's been trying to write games and multimedia apps using C++, it is a revolution. The Android NDK team has finally provided APIs for audio and input events that have made life pretty difficult for these guys. Not only that, they've added a framework that allows you to create an Android app without writing a single line of Java code. It's awesome :).

And that has me thinking now. We've had repeated asks and attempts from users trying to use CDT for iPhone development. And we've seen developers in the Android community using straight CDT or with the plug-ins that currently reside in the Eclipse Sequoyah project. I firmly believe that this is the next grassroots. As the computer industry changes, so do the developers and I need to make sure that the mobile app devs have a low barrier to use the CDT for their projects. Sorry Wascana and Windows, I need to change my focus.

Back to the Blogoshere

2010-12-04T16:56:00.001Z

I've been pretty busy lately. After a couple of years of looking at Eclipse based install technologies, I'm back working in the IDE space on some cool things based on the Eclipse Target Communication Framework. That's taken a lot of my time so I've resorted to Tweeting short ideas rather than spend the effort writing here on my blog. And I miss it and I have accumulated a lot to write about. So look for more in this space.

There are a few things I've been interested in lately. Android is still at the top of my list. I have a couple of phones now and am immersing myself in the experience to learn more about it, especially how apps are different from the now legacy environments we have on our desktops. Meeting the needs of app developers of course is important to us working on Eclipse based tooling and I think it marks a shift in the grassroots. Projects like Wascana which focuses on CDT for Windows dev are becoming less important to me than CDT for Android native so look for new things out of me there.

I'm also becoming maniacally focused on usability. This is a relatively new area for me after years of being a modelling and parser guy. But it is so important to create software that users want to use and it's a challenge. And I'm going to leverage my passion for writing to help. Writing user stories will really help me get inside their head. Not only do you need to understand what they are trying to accomplish, you need to understand why. It'll be cool to see how this works on practice and should be fun.

Well I'll write more later. The software world is going through some major changes thanks to both web technologies and mobile. Android and iOS have a great rivalry going and I expect to see the avalanche of mobile devices and even things like settop boxes that app developers are going to want to target. It certainly is a great time to be in this industry.

Historic Day for Linux Desktop?

2010-11-05T15:24:00.000Z

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

2010-10-30T18:50:00.000+01:00

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

2010-10-19T02:58:00.000+01:00

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

2010-09-28T21:05:00.003+01:00

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

2010-09-28T17:36:00.002+01:00

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

2010-09-24T19:35:00.001+01:00

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

2010-09-08T21:20:00.000+01:00

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

2010-08-23T20:30:00.001+01:00

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

2010-07-19T20:38:00.001+01:00

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!

2010-07-15T20:54:00.000+01:00

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

2010-07-13T21:05:00.000+01:00

"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

2010-06-29T04:10:00.000+01:00

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

2010-06-18T21:26:00.000+01:00

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

2010-06-10T20:40:00.001+01:00

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.

2010-06-04T16:24:00.002+01:00

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

2010-05-21T02:04:00.004+01:00

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

2010-05-14T16:46:00.003+01:00

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

2010-05-13T19:20:00.001+01:00

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

2010-04-29T18:19:00.000+01:00

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

2010-04-28T15:37:00.000+01:00

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.

Mac gets no love

2010-04-20T15:12:00.000+01:00

I should blog more. But twitter is so much faster. At any rate...

@timbray tweeted yesterday "Eclipse SPOD DIAF." After getting out my magic decoder ring, I soon learned that he was complaining about the performance of Eclipse on Macs. Apparently there were memory issues in Eclipse 3.5 Cocoa that causes a lot of garbage collection (assuming I'm interpreting that correctly). That causes the pause icon to pop up while Eclipse is locked down. The so called Spinning Pizza of Death, which is being asked to Die In A Fire, or at least so my magic decoder ring told me. Kids and their fancy lingo...

I hear that's fixed in Eclipse 3.6 and I haven't seen it in the few times I've run Eclipse Helios on Mac. But it's another episode in a long story of Mac not getting any love from the Eclipse community, or at least the contributors. The good news is that as more and more contributors are using Macs, these issues are getting addressed. But the perception has already been set free that Eclipse sucks on Macs and hopefully the Mac users are passionate about Eclipse to give it another try.

I ran into another case that confused the hell out of me last night. I was testing the new Android CDT integration I'm contributing to the Sequoyah project and had an NPE show up. So, as I do on Windows and Linux, I quickly tried to fire up my CDT workspace to take a look at the line of code the log was complaining about. You know, if you have an Eclipse running and you try to launch a second instance, it just pops up the one you have running.

From what I've been told, Mac applications are always singletons. You run one instance of the application and it's able to handle multiple documents. But that doesn't work in Eclipse because Eclipse can't handle multiple workspaces. I remember that coming up at the e4 summit as someone wanting to do that, but at the time I didn't get it. Now I do.

I imagine things like this will get solved over time (although the multi-workspace thing, I'm not sure). But it is a great example of how open source projects work. The only way features get done is if someone has a vested interest in getting it done. To date, there have been few Eclipse contributors with such an interest in Eclipse on Mac. Yes, that's changing, but pretty slowly.

Now, here comes the controversial part. What you don't see in open source much except for the few cases where projects are bankrolled by forward seeking companies with lots of money (i.e. Google) is projects investing before the need. We've known for a long time Mac was going to be important, the trends were pretty obvious. But open source doesn't work that way. The funding for development isn't strong enough to support risk like that.

Or so I think. I am curious if you agree and if you have a theory of why that is. I'm not sure how it can be changed, or if vendors who fund open source want it to change. I know of companies that don't want it to. But the companies that do easily trump that if they can figure out how.

No, I don't want to read e-mail on my dash

2010-04-12T18:39:00.000+01:00

Ottawa has a small hi-tech community, at least relative to Silicon Valley South and all. So, of course, the talk still hasn't died from RIM's acquisition of QNX from Harman. For us ex-QNXers and lovers of the mobile space, it is good folly to try and figure out what it all means.

What it doesn't mean is that you'll see RIM bringing your e-mail into your car. Yes, QNX has a big chunk of the automotive operating system space, but I can't see how RIM fits into that, despite what most of the industry pundits have to say when they first heard the news. And frankly, I worry about how advanced applications running in your dashboard is going to impact safety. I'm not going to be catching up on my e-mail while driving, that's for sure.

No, the more interesting angle is how QNX's Neutrino operating system will look in RIM's smartphones. I don't know what's in one of those today, but my guess is that their incumbent OS is really holding them back. They have the branding to take on Apple, but I have to think there's some technical reason whey their application development stack is relatively weak.

And I think that's where Neutrino will help them. I'm not going to get into why I left QNX, but it certainly wasn't faith in their technology. The microkernel architecture definitely has advantages, and I think it's a no-brainer that they'll be able to run RIM's existing stack on it. And I have to assume that RIM is working on additional stacks to support things like native game development, much as Android has.

So I think this is an interesting twist in mobile and consumer electronics and could give RIM a boost. And for QNX, they achieve one of their long time dreams of running in handsets. And I'm glad for them. But I still think Linux and open systems is the better choice ;).

CDT on e4

2010-04-09T16:23:00.000+01:00

I just got word of the available e4 Eclipse SDK test builds and thought I'd try out the CDT on it. The great news is that I had no build errors for the CDT base functionality (haven't tried our advanced debug views yet). And I was able to create a C++ project and build it. I had issues going into debug, but I am pretty happy on how far it has come.

There's still a lot missing, though, so there is much work ahead. And as I've feared the UI performance is quite bad, but there's a long way to go to clean these things up. I'll be keeping regular tabs on their progress and test as many of the CDT workflows as I can as the platform stabilizes.

Here's a teaser screenshot.

From Rocks Stars to Reality

2010-04-06T20:06:00.002+01:00

"at #eclipsecon we were rock stars, now back to reality."

I was sitting waiting for my flight leaving SFO when this great tweet came across my Twitter feed. It came from Kim Moir, and hit on a very important issue that many of us committers face when working on Eclipse.

Many of us work for companies where open source is a means to an end. We continuously fight to explain the value of what we do to business managers driven by revenue and profit, where they measure the price they charge for product based on the value it brings to customers. And frankly, old school businesses struggle to understand that providing free open source does actually bring value to customers. So we are often under the microscope and under pressure to fight for something we dearly believe in.

But at EclipseCon, the world is upside down. People we meet there are very grateful for what we do. We are the experts they want to talk to to get the information they need. They are the people looking to join us on our mission working to each other's benefit creating great software. Yes, there we are rock stars, or at least the community makes us feel that way. And we dearly appreciate and are humbled by it.

It's an incredible high and one of the reasons EclipseCon is always one of the best times of my year. And, yeah, it is a bit of a depressing feeling as you start on your way home. The show has ended again for another year and it's time to go back to our quiet offices, fighting for what we believe in.

We all dream of a world where our work is appreciated there as much as it is in the community. But it is the reality we deal with year after year. And maybe why EclipseCon is such a great time as it brings us together to celebrate the fact we've survived another year. Here's to surviving again and seeing you there at EclipseCon 2011.

Next step in the Android Revolution

2010-04-01T16:01:00.000+01:00

As everyone knows, Google has been working hard on amassing all human knowledge through their search engine, ad sense, their new DNS server, google books and many projects that haven't been made public. I was wondering what they were going to do with all that. It could be a pretty powerful tool.

Well, we finally learned today. Google has announced the next step in the Android revolution, Google Robot. They've been working on a robotics project and have Android running on a Beagleboard that animates the Android at the Googleplex. They've also been able to reduce all human knowledge onto a single SD card that is plugged into the board and the Android has come to life.

As it turns out, it's a pretty smart and powerful robot and has set it's sights on taking over all governments in the world. It's hard to argue with the strategy. At least they aren't using that knowledge for evil.

I love Android on my Nexus One. I love Android running in Google Robot. I for one welcome our new robot overlord. All hail our new benevolent leader!

Another EclipseCon in the Books

2010-03-26T05:05:00.000Z

Wow, what a week. I don't even know where to start. There were a lot of old familiar faces here, there were a lot of new people who introduced themselves to me. The CDT community is thriving and I am more excited about CDT's future now than I ever have been.

The main reason for that I think is that we're starting to go beyond our basic set of features into some things you won't see in most IDEs. The big one for me that only made a little splash is CDT's new Codan static analysis framework and it's current small set of checkers. Today, CDT will detect syntax errors and highlight them. But with Codan, we can now detect logic errors. Things that have traditionally made C development hard, like finding unbalanced malloc and free's, or new's and delete's, that lead to memory leaks, can now be checked for with the appropriate checker. It's pretty new and will only be available for preview in CDT 7.0, but I can't wait to see where the community takes this.

The other big activity in CDT is our new built-in debugger that gives us the ability to debug without having to rely on an external debugger. It's also in a preview state, but companies with special debug needs that aren't being met by gdb, have an opportunity to use a debugger much more tightly integrated into Eclipse, and fully licensed EPL. And no, we're not planning on a EPL compiler, just dreaming of one :).

I am also seeing things happening on the periphery of CDT that extend Eclipse's C/C++ development beyond our traditional edit/build/debug. Tracing and profiling are maturing. Support for a "best in class" Linux IDE. Debugging for massive multi-core. It's as though we've now solved the basics and are now focusing on the hard problems, and doing it in the open. It'll be very interesting to see where things go and how we manage the community to make sure we're efficient.

Along with parallel tools and Linux communities, I'm getting more involved with the Mobile projects. It's part of my role as an Architecture Council mentor to help them out. But I think there will be some overlap between Mobile and the traditional embedded that the CDT community represents. There was some great discussions this week in that area and I'm happy with the progress they're making.

But it's time to go home and back to the grind. The CDT community and the communities it intersects with are thriving and I can't wait to see where we end up by next year's EclipseCon, same time, same place, in 2011.

Totally Pumped about EclipseCon

2010-03-18T14:51:00.001Z

Well, it's coming quickly. EclipseCon for me starts with my 6 a.m. flight on Sunday in order to get to the Hyatt in time for Eclipse council meetings. EclipseCon is always a very busy week for me as there are always a few people that I want to run into and chat about CDT things. I made a conscious effort not to submit many talks this year to give me time to breath and to give others in the CDT community their time in the spotlight. It's going to be great.

The talks I am involved in are my own lightening talk on Wascana, my CDT for Windows effort that combines my work on CDT and my work with p2 to give Windows users a quick start using CDT for Windows programming. I'll be helping a few others including Ken Ryall on the CDT what's up standard talk, and Andrew Overholt with the Linux IDE long talk. And I'm involved in a couple of panels. Then we have the various BOFs that take place in the evenings including the CDT and Linux IDE BOFs. My calendar is almost full but there's enough space to meet the community and help prepare for all this.

Aside from the CDT things that I'm of course interested in, I have a couple of other things I'm looking out for. I'm curious to meet other people using p2 for their commercial install technology as we are doing at Wind River. It would be cool if we can standardize on some touchpoint actions and UI and such to share some of the work. I'll also be attending the git tutorial as I'd like to see the CDT being one of the early adoptors of git as our read/write repo, once it's ready, of course.

I'll also be getting more involved in the Target Communication Framework effort that Wind River has started and that is starting to get community interest. We'd love to work with the community to put together a standard communication framework that allows multiple tools to interact with targets of varying sizes and shapes. Martin O from Wind is giving a talk on that and we'll be holding a meeting somewhere along the way to plan out the next steps.

And, of course, there's the bar, the social focal point of every EclipseCon we've had, except maybe the DisneyLand one. We were so new then :). This is where the community cuts down the walls between the projects and we become the one bigger Eclipse community. It's quite a site to see the CDT guy talking to the XML Tools guy wondering what the Xtext guys are up to :). It's a blast. And I hope to see you there. And if you see me first, please stop me and say hi. That's what I'm there for.

The Patent System is a Mess

2010-03-04T21:42:00.001Z

I used to believe that this whole patent system was just a cold war. Everyone was patenting everything they thought of, mainly in case they got sued for infringement on something else, in order to counter sue. Then they'd go meet in a bar somewhere, have a few pints and work things out.

Well, unlike the real cold war, where everyone got smart and realized there would be no winner and just gave up, (and, yeah, there was much more to it than that, but humor me :). The software industry seems to be about to implode on itself.

Yes, I'm talking about Apple suing HTC. I am not a lawyer. I am only a humble software designer, but if I was afraid before of getting sued for accidentally borrowing someone's idea in my own design, now I'm terrified. Today I was working on a wizard to import existing code into the CDT. I bet someone patented that already and I'm freakin' scared.

O.K. I'm being over dramatic about this. And I'm sure peace will reign. But something's got to be done about this system. There are way too many common sense ideas getting patented. And it's killing the drive to produce great products. The iPhone was really cool when it first came out. But as we got our hands on it and used it for a while, we realized that is wasn't really anything special, and the user interface ideas they had are easy to implement. So was it worth a patent? Was it really an invention?

The telephone, electricity, the car, those were great inventions worthy of patenting. But patenting to what end. If whoever owns the patent to the automobile sued everyone who figured out how to make one, where would we be today? And isn't that a monopoly? Where's the fine line between protecting the rights of the inventor, and protecting the rights of the consumer?

At any rate, I'm just a humble software designer who's getting very frustrated about having to be a part time legal clerk to do my job. I just want to innovate. And you know what. If someone comes up with the same idea and doesn't use my implementation. Good on them. There are lots of smart people in the world. Does the patent system help them, or does it make them so frustrated they decide to go server hamburgers instead. (Melodrama hat off ;)

Knowledge == value

2010-02-23T17:46:00.000Z

I heard some wise words yesterday in a discussion over a new business venture. "If you know more than your customers and you know more than your competitors, you should be fine."

I've really been struggling to come up with a justification on how you can still make money in the tools industry. There is such a rich set of open source freely available tools that developers can easily download and adopt. And no matter how you spin it, those free tools cut into the value proposition of a traditional commercial tools offering.

But that's why it so important to focus your investment on unique knowledge areas that you have or can acquire. Developers still face very difficult problems that free and open source tools won't solve for them. And that's where the money is still to be made.

But the converse is also true. For a complete tools solution, you still need the entire stack. And for those things where knowledge is common place, which have the least value (sorry), working in open source is really the only way to keep the costs down to match.

Engineering is expensive. Having the right open source strategy is critical to ensure your business is successful. And that strategy needs to be continuously updated. What you might think is unique knowledge today could become common knowledge tomorrow and you need to have a transition plan to keep above the line. It's certainly a lot of work, but it needs to be done.

Eclipse Rules, Deal with it

2010-02-23T15:00:00.000Z

That's about all I have to say about that. Eclipse is what you make of it. If you want change, get in, get your hands dirty, and make change happen. I've been able to do that over my years at Eclipse. We have a pretty decent C/C++ IDE thanks to the hard work of the community. We've been able to work with the platform team to push a number of changes down into the platform, debug especially, and now with the flexible resources, and more to come.

It is a lot of work, but then no one gets a free pass. If you're passionate about helping with Eclipse's success, you can make it happen, if you have the desire to work at it and work with our great community. If you are just going to complain about things from the sidelines, you shouldn't expect much sympathy. And that's all I have to say about that.

Understanding C/C++ Build Systems

2010-02-22T19:53:00.003Z

My main development task on the CDT these days, when I get to tear myself away from other interesting things I'm looking at, is on a prototype of my dream CDT build system. I was involved in CDT's managed build at the very beginning but let others run with it as I concentrated on the CDT's source navigation features, parsers, and indexer. Now that those things are in really good shape and debug has a lot of good people working on it, I thought I'd take another look at build.

(BTW, I'm back working mainly on Eclipse open source these days after two fun years of working on commercial p2-based installer technologies)

Probably the biggest change over the 5 years since my first foray into build is that there are a lot of managed build systems out there now. Everyone seems to agree that writing Makefiles is hard but that there are patterns that can be deduced and can be codified in Makefile generators.

One of the earliest examples of that was the autotools used on most gnu projects. These tools generate configure scripts which then generate Makefiles and header files for given run-time configurations. The guys at Red Hat have a pretty good integration for autotools with CDT projects as a part of the Linux Tools project. But I know Jeff had a hard time putting the integration together and I hope to make that much easier.

There are others out there as well. CMake is very much like autotools, but a little more general and less gnu specific. It can be used to generate Makefiles for Microsoft's nmake and Visual C++ for example. There is an Eclipse editor for the CMake input files but it would be nice to be able to cleanly integrate it into CDT's build system.

Probably the biggest one on my radar is Qt's qmake Makefile generator. It's specific to Qt's structure, but does a great job of managing the build system for Qt projects. As Qt becomes more popular, especially in the device community with Maemo and now Meego along with Symbian and Qt's desktop offerings, it's important that we provide good support for it.

Along with CDT's existing build support for user provides builds (good ol' Standard Build), and CDT's Visual Studio-like managed build which has both a Makefile generator and an internal implementation of something like make, I think we need to be open to different types of build systems for the CDT. This is especially true for existing commercial products that have their own build systems created for their own specific needs.

It's my firm belief that the growth of the CDT, including into the commercial space, requires that the CDT be as similar as possible across all these different instantiations of it, both open and free and commercial. That way users can leverage what they learn from one instance and apply it to the next. Build has gone in many different directions, but I hope to try and bring at least a little unity to what is otherwise a bit of a mess.

Mapping the Mobile Platform Landscape

2010-02-16T18:53:00.001Z

I just spent my lunch time going through the Maemo forums to get a sense on how that community is reacting to the announced merger of Maemo with Moblin to form MeeGo. Many of them aren't taking it well, but I think that's more about fears of the uncertain future than anything real. And it's happening even with assurances that things will be pretty good for them in the end. At the very least it's a great place for this community manager to see different community management strategies at work.

Community angst aside, I was pretty sure this merger was inevitable. The underlying packages that these two Linux distributions were using were very similar so the end distribution will be easy for app developers to adapt to. But there are a few differences in vision, which will actually affect Moblin developers more, especially the focus on Qt. In the end they seem to be making the right technical choices so I think it'll work out well for everyone.

But this merger is a disturbance in the force and it's probably time to take another look at the choices of platform. Here are my current thoughts on each, again from an app developers perspective, not a platform vendors one:

iPhone - by far the biggest ecosystem, despite being closed, single vendor. The great API and promise of riches still attracts app devs.
Android - up and comer. Pretty good Java API but I'm still awaiting on a great native API to propel Android. Open(-ish), runs on many handsets, and people are getting it to run on different devices and architectures too including MIPS and x86.
Symbian - now open. From what I hear and saw in passing, the API is pretty poor, but Qt will fix that. Not sure about new device wins, though.
Windows Phone 7 - closed but powered by the Microsoft machine. The Windows API is generally pretty poor, but people put up with it to ride the wave. Don't count Microsoft out yet.
Palm - struggling ecosystem, great Web-based API, but not sure that was the best strategy to win app devs.
MeeGo - not a big fan of the name, but the main GNU/Linux platform in the bunch (Android is Linux kernel only, Palm Pre is very linux, though). Qt is a great API. Promises multi-device and support for both ARM and x86. Could be a contender.

At any rate, it's a big list and all of them are strong enough to consider, which is going to make an app developers life a bit of a hell for a while. iPhone is the clear leader and I don't see that changing. Depending on what devices MeeGo end up on, it could take a bite out of Android. And, Windows Phone, it's hard to count Microsoft out. Symbian still leads by volume, and Palm can make a fight out of it if they provide a good native API.

As I keep saying, it's a great day to be a software developer with all these great technologies to learn. And it really is my hope and plan to make Eclipse-based IDEs the choice for all of these. If you hope to reach the largest audience, you'll need to target more than one mobile platform and being able to use the same IDE for all will be a big win for mobile app developers.

OK, Eclipse, you have 3 seconds...

2010-02-11T00:21:00.001Z

Interesting enough, I had a couple of different conversations over the last couple of days on the topic of "What do we still need from Eclipse for it to be successful". The context of success is the areas I work in of course, the CDT user space and Linux and Embedded in particular. Here, as I've blogged many times before, we still face an up hill battle to get developers to use Eclipse for their IDE.

From what I can see, it seems to come down to performance and start up performance in particular. Our users can easily and very quickly bring up vi to edit their code, run make to do a build, and fire up gdb to debug. That's the workflow they are used to and their first reaction to being introduced to Eclipse CDT, which does a great job of wrapping this workflow, is "man that took a long time to start up."

Start up performance isn't all of the story. Many of the workflows in Eclipse are pretty foreign to them as well, but right now I'm focusing on the performance issue and whether there is anything we can do about it. I know there have been task forces over the years that tried to address it. I remember getting bugged about the CDT running at start-up. So if you have any information about the progress of those I'd be interested.

I guess to make the problem even more serious, we are getting compared with other IDEs, like Qt Creator and Visual Studio, which take maybe half the time or less to start up than Eclipse does. And it's hard to justify to potential customers and users why that's OK. It's something that's starting to get critical and we need to find an answer.

So, the challenge is, can we get Eclipse to start up in 3 seconds, about the most users will notice, a guideline I've used for other UI operations over the years. And it's not just an objective. It's time to start treating it as a hard requirement. People wonder why I'm a little negative on e4, this would be one of the reasons. My users need start-up performance addressed. And that will require a pretty radical change in thinking that will be at odds with many in the community.

But we need to start having the conversation. I'm looking forward to reading your comments. Please let us know what you think pro or con, or even potential solutions. The one I got from twitter that I like the most is rewriting Eclipse in C++. But I've said that before. Anything more practical?

Running to be YOUR Committer Rep

2010-02-09T03:50:00.003Z

We're out of the gate with the Eclipse Board of Directors election and I'm running to be a Committer Representative. You can check out myself and the other candidates and our platforms over at the Eclipse election site, http://www.eclipse.org/org/elections/nominees.php.

My platform is simple. My biggest concern as I've documented on my blog a number of times over the years is how to get more contributions into Eclipse projects. We often complain of being starved for resources. Even this week on the cdt-dev list, we're struggling to get our new debug framework into good enough shape that it will attract further contributions. The community is coming together and rising to the challenge, but it would be great if it was easier to get more people involved. The more contributions you get the more everyone benefits.

To me so much of the answer lies in ways to simplify the path for individual contributors to get code changes upstream into the Eclipse repositories. Many are unable to get employer approvals to get committer status, but we should still be able to leverage their talent. Distributed source control is a great start, allowing downstream developers to work on their features, allowing committers to see and review their work and then push that work upstream, all while meeting the Eclipse IP processes that are so valuable to our membership. We need to make sure we continue the work to complete that infrastructure, and that the Foundation staff have the necessary resources to make it happen, and that we make the necessary changes to the Eclipse processes to make it simple.

I'll blog about other ideas over the upcoming days, and hopefully earn your trust enough to vote for me. As Ed put it, my approach to this blog tends to be edgy. But that's a facade I put on it to drive my ideas home. If you take a look at my work on the CDT, you'll see I try hard to be pragmatic. I present my ideas and always consider not only the ideas of others, but try to understand their needs as well to make sure we have a consensus from which we can all benefit. It's a lot of work there, and I expect it to be an even bigger challenge on the board. But after 7 years of active involvement in the Eclipse community, I feel I'm ready.

It's all about the App Developer

2010-02-08T16:47:00.002Z

In case you missed the news, Symbian has achieved it's goal of being a fully open source operating system. Before I start, I have to congratulate Lars Kurth (former CDT guy) and the gang at the Symbian Foundation. It's an incredible effort to take a commercial product and clean it up to be consumable under an open source license. To finish ahead of schedule is a tribute to the passion and dedication the Symbian guys have for this new direction. Very cool.

But as much as I appreciate the work they did, I do worry how well it'll succeed. Yes, I'm open source guy and am a huge fan of open source projects and working with diverse communities coming together for a common goal. But at times, I don't think it's enough in order to be successful, especially if you are in the platform business.

Funny enough, while I was calling people "Apple Fanboys", someone called me a "Microsoft Fanboy" (I didn't even know it was possible for someone to be a Microsoft fanboy). But yeah, I appreciated how Microsoft built up their app developer ecosystem. Even though it's all closed, Windows is still massively successful, thanks mainly to the apps people build for it. The same is true for Apple, obviously. There's a reason why 150,000 iPhone apps headlines their marketing material.

The important difference I'm starting to realize is that open source platforms appeal to platform developers, the guys that port the platforms to new devices. Having an open source platform helps get you on to more and more devices as the barrier to entry is much lower, or at least the run-time royalties are much lower.

But it's applications that drive device sales and application developers are a different bunch. You need a great set of tools and a great set of APIs and a great ecosystem with promises of riches to appeal to application developers. And that's independent from how open your platform is I'm afraid.

With all these mobile platforms entering the mainstream, it's a big fight for app developer mindshare right now. And that's a much bigger fight than for platform developers. Either way, it's a great day to be software developer!

iPad, iShmad

2010-01-29T18:58:00.005Z

I was just having a conversation with a colleague over Twitter on the merits of iPad and Apple's A4 SOC that powers it. I, for one, am not an Apple fanboy. He is, so it makes for good fun. So when he's glowing over the "fascinating" A4 chip Apple is producing, it's easy fodder to point out that there are many SOCs out there that pretty much do the same thing. And I'm inclined to believe the pundits and I don't think it really is that fascinating at all unless you find good power management fascinating.

The main reason I'm not an Apple fanboy is because of Apple's strategy of locking in the developer. If I could build iPhone apps from my Fedora Linux laptop, then I'd be all over it. But I can't, and as the CDT Mac crowd knows, I don't have a Mac to use as a development environment for iPhone or CDT, and I'm not interested in putting my own personal finances towards one. There's nothing on the Mac I can't do using Windows or Linux, so I can't justify it.

Now, aside from the incredibly crude yet funny activity on Twitter about things the name 'iPad' reminded people of, I found the iPad keynote to be a bit of a yawner. Yes, it looks like a nice manifestation of the tablet format we've been speculating about, but that's all. It's nice. It certainly isn't revolutionary, unless you count being successful in the tablet business as revolutionary, and there still isn't proof that'll be the case. Mind you, if the fanboys put their money where their collective mouth is, it should be a slam dunk. And that's the credit I do give iPad, it does validate the tablet form factor.

The big difference now compared to when Apple did launch it's revolutionary iPhone is that there is a lot of other noise in the tablet space right now and even similar product announcements (Similar products that is, nothing compares to the hype machine behind Apple's announcement). Check this article for a list of 9 iPad alternatives. All fine devices in their own right.

I think Android makes a great competitor for Apple's mobile devices. I am an Android fanboy because I can develop Android apps on my Fedora laptop and my Windows machines at home, and yeah, if I had a Mac, I could build Android apps from there too. They give you a pretty good SDK to work with on any platform you like.

I'm also keeping an eye on Moblin as Intel enters this arena. It should enable a similar development experience, although purely native instead of Android's Java/Native stuff I have to jump through. And it is real Linux which lets me use the same SDK to build desktop Linux apps.

So Apple fanboys, enjoy the show, go put your money into the coffers at the church of Steve Jobs. I'm just glad it isn't the only show in town.

Doug's Open Source Manifesto

2010-01-22T20:38:00.008Z

I've done a lot of thinking lately about why companies should invest in open source. We complain about the "takers" as an Eclipse committer community; you know, the companies that take advantage of the hard work we put in never to see that hard work reciprocated. Complaining doesn't help. We need to be able to sell them on the need to contribute. Yes, need, and I think I am starting to understand the whole thing. So here's my "Open Source Manifesto" for what it's worth and I'd love to hear what you think in the comments below. You may know all this already, or maybe I'm totally off base, but we need something like this.

Open Source Software is an Asset

I wonder if anyone has counted up the number of lines of code of software that sits out in the interweb free for use by anyone, restrictions or not. Companies go through to great lengths to protect their proprietary code as they would any other asset. Well all that open source software out there is also your asset if you chose to use it. Protect it, manage it as you would any software you have available for your product. And you can bet it's worth much more than any software you have or could ever build in house.

Open Source Developers are Business People

Sure there are a lot of projects that are run by hobbyists or students, but the biggest projects, the most important projects out there have far more corporate employees contributing and managing them than not. And for the most part, they're easy to deal with as good partners in business can be. Depending on how you participate, you can have much more influence on open source projects than you think, sometimes even more than you have over internal projects.

Influence by Contribution

This is the key to successfully managing the asset. If you want influence on an open source project, you need to contribute to it. And the math is simple. The more you contribute, the more influence you have. But you don't need to go crazy and fully take over a project to be successful with it, and for the most part you don't want to. Open source projects are quite open to contributions. Take advantage of that.

Take your place in the Community

One of my biggest thrills in open source is working with great developers from other companies. You may be tempted to fully control a project, but if you want to benefit from some of the greatest minds in our industry, you need to let others drive the boat once in a while too. Understand your place in the community and how the things you do influences it, both good and bad, and make good decisions about how you participate.

Have an Open Source Strategy

Don't just wing it in open source. Part of being able to acquire influence on a project is building up respect and trust with the rest of the community. If you are a fly by night organization that jumps in with big plans without having a track record, it'll be hard to achieve that. Invest in open source with a long term plan in mind. Come, stay a while, build up the trust, and you will be rewarded at the end of the day.

Don't compete with Open Source

If you have a product that competes with an open source offering, or maybe offers something similar just a little bit better, don't kid yourself. Sooner or later the open source offerings will become better than yours. Again, it comes down to the investment and the fact that there's more corporate investment going into open source than you can do yourself. And if there isn't now, there will be. The momentum is unstoppable at this point.

Understand your value proposition

At the end of the day, customers are looking for good value in their software purchase dollars. They don't care how you built that software or even if you did. They just want you to be the best supplier of that software in the business. Sure, they'll threaten that they can get good open source software for free, but if you focus on making their adoption of that software easier, provide things that the community doesn't, you can add value, lots of value. Open source projects focus on source code. A good software company knows there's more to good software than just good code. There's lots of room to make money here, and in turn it should be easy to justify the investment you do make in open source.

Well, that's all I can think of for now. But I'd like to continue evolving this manifesto into something all us open source contributors can bring to the companies out there and help them justify making the same investment in open source we are, to join in the fun and the profit.

CDT Needs a GDK too

2010-01-15T17:06:00.002Z

A lot of people who come to the CDT have used Visual C++ in their lives so we strive to make certain aspects of the CDT familiar to them. That requires taking a look every now and then to see what things are like over there, and with the free Visual C++ Express, it's interesting to see how the other side lives.

I sauntered over to the Visual C++ Express web site and I guess it's been a while since I've been there, or maybe it just struck it differently than it has before. The web site promoted Visual C++ Express as Simple, Fun and Easy to Learn. We can argue whether VS is simple and easy to learn, but it was the Fun part that hit me as a great idea. This section highlighted Game Creators GDK, Game Development Kit. I can see how that would attract VC Express's target audience, prospective future full Visual Studio edition customers.

We need something like that for the CDT. We need to make the CDT Simple, Fun, and Easy to Learn. Get the kids to use it and when they become future prospective clients of CDT vendors, they'll be quick to adopt their CDT based tooling. First we need to fix some of the major usability issues with CDT. A lot of CDT users will argue that it's not particularly Simple and Easy to Learn and that needs to be addressed.

But the Fun part comes from using the CDT to build something fun. And as Microsoft has figured out, game development is fun. I've already started looking at what would be needed for a GDK for Android and there are a few open source components that can go into that. And make it cross platform for Windows, Mac, and Linux and it's variants like Moblin and I think we could have a GDK for the CDT that would be a great injection of Fun into Eclipse.

Looking Forward to 2010

2009-12-29T17:21:00.001Z

Last year I put out predictions for 2009. But I don't want to look like I know things that I really don't. So instead, for 2010 I'm going to list the technologies I am most looking forward to seeing come to fruition this year. As a tools developer, it's important to know what things your users will use your tools to build, and for that you really need to know what's going on in the industry. So here we go. I'm also going to forgo my standard 4 or 5 paragraph length so excuse the extra long post. It's just easier for me if I capture them all at once.

Mobile

I blogged about this in the past, but what I see happening in the mobile space reminds me so much of the revolutionary days of the early PC market, back in the late 70's and early 80's when the ability to program computers came to our homes. The same is now happening with mobile devices, all of which have freely available tools and SDKs and anyone can, and is, writing applications for them. And a rare few are even making money at it. It's a race to see who wins and despite the early lead by Apple, it's not entirely obvious to say who will.

In 2010, the momentum will continue to grow. Tablets will be the next battle ground. They should be in the 7 to 12 inch screen size range making them more useful for web browsing than smartphones. They may or may not have a keyboard so we'll have to get used to using soft keyboards with these things, although, there are rumors of patented technologies that should make it easier. And I expect the power of the SOCs used to build these will grow to make them great little gaming machines.

My main interest in this area is Android. I expect to see Android on more and more of these devices. Right now, I find the Android SDK (including the native development kit) weak for gaming and multimedia and hopefully that will be addressed this year. If it is, it will be a real challenger to iPhone.

New Linux UI

Moblin is currently leading a revolution in the Linux GUI environment space. I think it really brings Linux to the masses with a very clean social networking focused interface. Hopefully we'll see a wider deployment of it this year, especially on netbooks. But I expect they'll continue to push it down into the MID space to challenge Android and iPhone there.

The main reason I like Moblin is that unlike Android it really is Linux and uses the same SDK set that you have on Linux desktop. It's the best hope for seeing applications that are easily ported between the desktop and mobile devices, other than web apps, of course.

The other advantage of being Linux and being open source, is that the underlying library that drives the UI effects in Moblin, i.e Clutter, is available to the desktop programmer too. I am very much looking forward to what the Gnome gang have planned for it in their upcoming Gnome Shell 3.0. I am hoping that this and other changes to Gnome for the September 3.0 release will be a real game changer for desktop Linux.

Blender 2.5

What the heck is Blender? And why is a C++ hack like you interested in it? Blender is an open source 3D modeling tool. No, not software modeling, but the real 3D object modeling that you use to build games and simulations. I've been watching the game development industry mainly because I'm a geek with an insatiable curiosity on how developers build things. Building games is one of the hardest computer science problems around. That and you need great artists to make great games. It's a very cool mix of art and science. And the artists need tools too.

The Blender community is a rich mix of that and it's been fun to watch them. The new version of Blender coming out this year is a much needed rearchitecture and a bit of a reinvention of themselves. It looks to be much easier to use and I expect it'll become quite popular. Mix that with the open source software development tools we're doing at Eclipse and I see a much lower entry point for people wanting to join in on the fun.

High Performance Computing

HPC is another technology that I see inching towards the masses. The hardware that the graphics card vendors are putting out is reaching dizzying heights of multi-processing. As the tooling for these cards improves, this power will be more and more accessible to the every day programmer and it'll be very interesting to see what they build with it.

C++0x

I'm not sure whether C++0x will reach standardization this year, but I expect to see more and more of the spec implemented in GCC and other compilers. There are a lot of important new features here for C++ that will greatly improve the productivity of C++ programmers. Will it be enough to fend off the continuing progression of developers to less capable languages? I don't think so since it's still a pretty complicated language. But it should make it more appealing for those that need the power of C++.

Open Source Wins

I usually get called the "Open Source Guy" at work by those more focused on business. But I will continue to champion the need for open source software as a key element of any software business strategy. Why? Because software is damn hard to build and going it alone continues to carry a high risk of failure. If there are opportunities to work in a community, to share in that risk, and to spread out the cost so you aren't covering all of it, how does that not make sense?

At the end of the day, customers care that you give them great solutions, they don't care how you build it. If you ignore all the great work that's going on in the communities, you'll need to keep ahead of that to ensure that they see you as the best provider of those solutions. That doesn't mean competing with open source, that means embracing it and leveraging it to keep your customers happy at a reasonable cost.

Over the years, we've seen companies that have slowly embraced this strategy. Some have a ways to go before they totally get it. Notice that none of the technologies I see as industry changing are coming from Microsoft. But they are keeping a close eye on what's happening in the communities and the little test balloons they've sent over the last year will continue. And I take that as a sign we are right.

Well, that's all for now and thanks for sticking with me to the end. 2010 is going to be a great year for software development. We seem to have broken free from the shackles of the doldrums we've been in since Windows took over our world. It'll be very interesting to see where we end up at the end of the year, but it promises to be one hell of a ride.

Reviewing "Predictions for 2009"

2009-12-23T21:58:00.001Z

I spend a lot of my time thinking about the future. As an architect, that's probably the biggest tool in your tool belt, a crystal ball. The best designs are the ones that can be used now and a year from now.

Before I blog about what I think will be important things to look out for in 2010, I'd like to review what I said last year about 2009. If it turns out I was totally wrong, then you can take my 2010 predictions with a grain of salt, as you should anyway. So here we go.

2009: The Year of the GPGPU

Well, I'm not sure it was as big as I thought it would be, but we're certainly seeing a lot of momentum behind ATI and Nvidia's monster graphics cards come computing devices. We're still fighting software demons. Nvidia is still pushing it's own CUDA over the "standard" OpenCL that ATI seems to be more on side with. But if you see what some of Nvidia parters are putting together with their Tesla boards, you know the time is soon.

2009: The year of WebKit

While not very visible, WebKit is becoming the standard browser platform for devices including iPhone, Android and Palm Pre, along with the existing desktop browsers, Apple's Safari and Google Chrome. But if you've ever tried to use Chrome as your default browser, as I do, you still run into a lot of web sites that don't render well on it, or AJAX sites that don't even work. Even our EclipseCon submission system had trouble with Safari (although it seems to work fine in my Chrome on Fedora). No, it's actually looks like 2009 was the year for Firefox which is now the most popular browser according to something I read the other day.

C++0x won't be C++09

Now, I already knew that when I wrote it. If C++ creator Bjarne Stroustrup doesn't think it'll happen, it likely won't. I'm even having doubts it'll be C++0a (or C++10, I guess). But I hope it comes soon since it has a lot of great things that C++ developers need that a lot of other languages already have (like lambdas). The good news, is that we've started work on supporting C++0x in CDT's parser. It's going to take a while so it's important we start now.

So all-in-all, it wasn't a total failure. But then, I think I was probably stating the obvious at the time. There were no shockers, but it was fun to do. I'll give my thoughts on 2010 just before the New Year so stay tuned.

BTW, I'd also like to share my best wishes for the holiday season with you all. It's a time for reflection and I'm sure I'll do my share. 2010 is going to be a big year for me and I'll need to prepare. Merry Christmas to all!

The path to a successful e4 introduction

2009-12-23T03:56:00.000Z

The last time I blogged my thoughts on e4, I got quite a storm back at me. I don't have much against e4, and frankly, I'm not to concerned about it. I am the C++ guy and in my opinion, we should be making tools and libraries to make rich client applications easier to build in C++, which is what most rich client apps are built with anyway. But while a lot of what e4 is surrounds innovation around RCP apps, the intention is that it should go beyond that. We should be able to leverage e4 in our tools.

My fear, confirmed by many, is that the projects won't invest in e4 to ensure it gets adopted by the tools on the Eclipse trains. But, it's not really that. It's that the vendors that pay the committers working on those projects aren't interested enough to invest in it. All the begging and pleading won't really change that. In my years of open source experience, I've only seen that work when there was an obvious need that was going unfulfilled. I'm pretty sure that's not the case with e4.

So if we want e4 to succeed, it's up to the community to make it happen. In fact, I've challenged the Eclipse Architecture Council to lead the charge. If we believe in this architectural change and are sold ourselves that it needs to succeed, we need to take on the task of selling it to others, especially the vendors from whom we need approval. It should be what the Architecture Council is about.

How we do that? We need to show e4 running. In particular, we need to show prominent projects from the train running on e4, if not the entire train. And, of course it needs to work well and be easy to do, i.e. cheap. That requires a really good compatibility mode for e4, which is promised by the e4 team. And we need volunteers to do the builds, report bugs, and fix them.

"Build it an they will come" only works in baseball movies. Nothing sells a new idea like showing it in action and proving how easy it is to adopt. That will take work. Hopefully we'll get the few bodies we need to get the ball rolling and give us something to run with. If we have enough people that care about e4, this shouldn't be that difficult to accomplish.

"Eclipse Labs", the Eclipse game changer

2009-12-07T22:02:00.000Z

Ian hinted at it in the recent flurry on Planet Eclipse and Mike just offered an extra teaser. For me, the concept of an Eclipse forge, or "Eclipse Labs" is set to change the way open source developers see, consume, and contribute to Eclipse, and more importantly, to dramatically change the culture at Eclipse.

Everyone seems to be looking for a technical solution to keeping Eclipse relevant, e4 case in point. In the end, that's not enough. We need to grow the Eclipse community beyond it's traditional realm of corporate engineers, into what we more traditionally think an open source community should be, free. Free to work on what you want, free from someone saying no to your contributions (within reason, of course). To be free as you are when working with SourceForge, but still be a member of the Eclipse community.

I'm still waiting to hear the details on the rules and mechanisms for the Labs. But if it turns out like I think it should, ;), then I'm super pumped. Pumped enough to bring Wascana out from the freezer and make the real Eclipse C/C++ IDE for Windows that should rightfully be an Eclipse community project, not hidden out on SourceForge. That will require the Lab to ship GPL'ed software, i.e. the GNU tools, and LGPL libraries. Is Eclipse ready for that? I'm hoping.

Multi-Core Programming, Paradigm Shift Required

2009-12-03T03:55:00.003Z

I just caught myself sending 4 tweets in a row on the same subject. That's probably a sign I have a blog entry topic at my finger tips.

I was reading an article entitled "Microsoft's top developers prefer old-school coding methods". Whoever picked that title clearly missed the point of the panel discussion he was covering, but it's an awesome read.

The panel involved a handful of distinguished engineers from Microsoft and they were discussing the future of programming technologies. And hilarity ensued! It reminded me so much of the discussion we had about JavaScript at the end of the Ottawa Eclipse DemoCamp last week. There was much hilarity ensuing there as well.

At any rate, I totally agree with what these guys are saying. Everything we're doing to innovate in programming around graphical programming languages and concurrent programming is crap. Here's some of my favorite quotes from the article:

re graphical programming: "when you have 500 things, graphical programming is completely unusable. You zoom in and zoom out and you lose all context. I think it's just smoking dope." (a similar comment was made about using JavaScript to build complete apps at the Camp).

re managed code: "lets developers perform above their level of competence. It's like antilock brakes". (They were talking about CLR, but I'd include Java in that).

re abstractness: "programming is getting so abstract, developers will soon have to use Microsoft's Natal to write programs through interpretive dance." (That I don't want to see).

But the one quote that really confirmed what I had been thinking about multi-core programming: "It will be a long time before parallel programming becomes mainstream. Because of the bias towards sequention programming, we'll still be reinventing ourselves as parallel programmers 12 years from now."

This was a classic Ward Cunningham "A-ha" moment for me. I had hoped graphical programming could be an answer to break the sequential rut we're stuck in. But the usability of building complex programs graphically kills that. I think at the end of the day, we still need to look at hardware description languages such as Verilog and SystemC as holding the key. They are all about concurrency since the hardware they model is too.

Diversity is not the only answer

2009-11-30T03:47:00.001Z

Dave Carver started it and Pascal fed the fire. If you missed it, there are confusing and highly inaccurate statistics captured by the Eclipse Foundation that measure diversity in the Eclipse projects. Stats or not, there are a lot of projects where it's clear, there is one vendor paying a very disproportionate number of comitters that work on the project. And it's not always IBM.

But I think that misses the point. For open source projects to survive you need one key ingredient. Be OPEN! Simple, no? One reason that non-diverse projects suffer is that most of the decisions are made behind closed doors at that company. How many times has some feature or project just showed up one day, all the key decisions leading to their creation happening hidden in meeting rooms instead of out on the mailing lists. What kind of trust does that build?

A couple of Eclipse Summit Europes ago, I received the biggest insult I ever recieved working in open source. Having just joined Wind River, one of the attendees suggested that the CDT was just a Wind River project. After all the work I've done and career limiting decisions I've made to be as vendor neutral as possible in my work on CDT, I was hurt. But it drove home the point. Wind River was the elephant in the room, at least by perception, and that hurts trust.

I think Eclipse has a lot to learn from other successful open source projects. If we truely want to continue the success, we need to be real open source projects, not only in governance, but in culture too. That starts by dropping the vendor centric nature of the Eclipse projects and opening them up to everyone.

Linux Distros, The Great Melting Pot

2009-11-24T20:57:00.000Z

I've been talking a deeper look at Fedora lately as Fedora 12 was just released and I was checking out all the MinGW cross-development packages available there. While I was there I looked across all the packages included in the "Everything" folder. I even gave eclipse-cdt a try and was impressed to see 6.0.0 there (although 6.0.1 would have been more impressive ;)). It's also impressive to see so many of the Eclipse projects represented there. And just looking at the breadth of open source content, almost every open source project I've looked at is included, including the bullet physics engine, OGRE and Irrlicht game engines, blender the 3D modeling tool, clutter and mutter and even an early preview of the new Gnome Shell.

It's an incredibly rich set of libraries and tools, and it's got me jazzed for Linux again. And given the corporate virus scanner has finally found my Windows 7 install and is doing it's best effort to kill performance, I'm thinking again of going back. Windows 7 is pretty and I'm very productive in it, but I can see that the Gnome Shell has some of those same characteristics as I played with it on the Dell Mini.

The Linux distros are a great melting pot of open source technologies, and I think Eclipse is perfectly positioned to be the IDE of choice to work with those treasures. But playing with it, there are still a lot of architectural challenges we need to overcome to get there. Even just loading Photran (the Fortran tooling) and CDT together is a mess as both projects try to present pages for the properties. The big challenge we face in the Eclipse community is working together to make this better. I've mentioned this before, but the projects really do operate as silos, even Photran and CDT and we've tried hard not to do that, it's just too easy.

But it takes a group of people with the vision and the gumption to drive that vision home. I'd like the Eclipse Architecture Council to be that but as with all things Eclipse, it's really up to committers and the vendors that pay them to make this happen. Here's hoping someone does.

Chrome OS, it is what it is

2009-11-20T18:41:00.001Z

I guess I got caught up in all the hype over Chrome OS. It's an idea I've bounced around for years as I mucked around learning about embedded Linux. Replace the standard Linux desktop UI with only a browser and throw it on a mobile device. With everything on the web these days, or at least a minimal amount to do something useful, why not?

But I could never escape the idea that you had to have at least some local applications to do things when disconnected, or to take advantage of the CPU and graphics power using native tools for things like games and multimedia.

So I downloaded a build of Chrome OS from gdgt.com to give it a try under VirtualBox. And, BTW, you got to love the tech community and how quickly they get activated when something cool comes along. While the release is about a year away, and the build shows it, you do get a sense of what Chrome OS, or Chromium OS which is it's proper name, is.

You log in with your Google account and, bang, you're in the Chrome browser looking at your Google stuff.

But it is what it is. There's no application menu, no app market, or anything like that. Everything you do is over the web. I did notice an extensions mechanism, and maybe that's how you take advantage of the native environment, maybe not.

When I had thought of a Web OS, this summer, my thoughts turned to the Eclipse Run-Time and using that in conjunction with the browser to have local apps written for the Eclipse platform. I would also think you'd want to launch 3D and multimedia content full screen, or something. But that's not what Chromium OS is. It's web or bust.

So while Chromium OS is interesting, I'm way less excited about it. I think the door is still open for a netbook Linux platform that combines local native apps with the Web experience. Moblin is certainly making strides there for the consumer space. And I've been trying out the GNOME Shell which offers an experience much like Windows 7 for the power users. This story isn't finished yet.

Visual Programming for Multi-Processing

2009-11-10T01:42:00.000Z

I spent a little time on the weekend taking a deeper look at the Unreal Development Kit (www.udk.com), and I continue to be shocked that they are giving out all this great technology to you and me to play with. And it really blew me away when I saw their Materials editor. There's a tutorial here, http://udn.epicgames.com/Three/MaterialsTutorial.html.

Take a look at how you program the materials algorithms. You lay them out graphically and hook up data flows between components. The order of execution or the parallelization of the algorithm is automatically inferred by the declarative nature of the model. When you're ready, these get generated into optimized shader programs that download to your graphics card when drawing the 3D models that these materials wrap. Very cool and very efficient.

This is very similar to what I found with the SynthMaker program that came with the FL Studio audio workstation software I've been playing with too. There you define the algorithm for software DSPs and GUI controls that change values using the same paradigm.

To see it in two places now, I'd love to have this available to the general public for any kind of application. Would it really be more efficient to write general multi-threaded and multi-process algorithms that way or would the modeling tools get in the way. Epic and SynthMaker felt it was right for their users, is it right for everyone? You know, I bet we could build this using Eclipse modeling tools and try it out...

Openness Shades of Grey

2009-11-07T16:12:00.001Z

Motorola's newest phones are hitting the streets and promise Android goodness thanks to the latest Android release 2.0. Now if you think of Android as an open souce platform, you may have run over to the Android Open Source Project and tried to download the 2.0 source to see how they made it.

Uh, no. Android isn't that open. In fact, neither is it really a project. Android developement is really done on internal trees at Google and at the various device vendors. And the Android gang are pretty open about that on their mailing lists. I just wish they'd drop the open and project and just call it Android Source.

The unfortunate thing is that many in the community are naive to the shades of grey that exist in our industry. And complaints in the open tend to give projects a black eye. But each level of greyness has its purpose. For Android and most other projects that Google does, they want the flexibility to evolve the platforms quickly. Like it or not, truely open developement is slower.

Other projects need to be open to help grow the popularity of their technologies and to find people to help them build it. That's certainly what drives us on the CDT to be as open as we can.

The Eclipse Platform is an example of how projects change as their needs changed. No one complained when IBM started the Platform project 8 years ago and maintained almost full control of the project. It was necessary to ensure a great start, which it did. But over time, they've opened up as they realized they couldn't do it on their own any longer. So you change to maintain success.

I think the shades of grey are fine, as long as the licensing allows downstream projects to be as open as they'd like. And I see that happening with Android with the Android x86 project, for example, which is very open and just incorporated someone's code for better 3D support.

It's all good. People need to take a good look at the projects they follow and understand why they are structured the way they are to manage their expectations.

Unreal Development Kit

2009-11-06T20:16:00.001Z

Wow. Unreal Development Kit. Free. Or at least free for free content. I've always wondered how developers create content for the big game engines, id and Unreal. And now I know and I have it installed on my laptop. For free. Can you tell I'm beside myself here. Check it out: http://www.udk.com.

At any rate, Epic has released their development kit for free. It's a great gesture and a great way to get hobbyists and students and even small start-up shops using their engine. It seems to be complete, including their famous editor, amongst a plethora of other tools that help you create full games that you can distribute (for free, of course, otherwise you'll need to pay for a license as you should).

Looking back at the archives, my second blog entry after saying "Hi", was on digital content creation tools for Eclipse. I conjectured that having such tools would be very cool. And I think it still would be.

And playing with the UDK, I don't see any technical reason why such tools couldn't be created using Eclipse technologies. With integrations with the various programming language and domain modeling frameworks and tools, and being able to run on Windows, Linux, and Mac, and target those and game consoles and mobile devices, what a great game development environment that would be.

That was my dream for Eclipse back in 2005, and it's still a dream I have for it today. All it takes is a community of like minded dreamers to make it happen. Oh, and some money to pay for the dreamers. Thus the dream...

It's Crunch Time

2009-10-22T17:11:00.001+01:00

I haven't blogged in a while so while I have my head above water, here's a few notes on what's happening lately.

It's crunch time for me and my Wind River Installer team as we put the final touches on our next release of our p2-based installer. Our focus now is on on-line updates and installs which is a pretty exciting capability for our customers and support teams. I haven't blogged much about what we're doing there but I think it's time to start spreading the word. p2 is a great install engine. It can be used for more things than just OSGi bundles.

Unfortunately, our p2 stuff is intermingled with older install technology and what I can only describe as "legacy" UI framework. So we can't contribute much from that yet, but I want to switch focus and replace our legacy with a more modern framework, that we can use to replace the p2 UI that exists today. You really need to understand p2 to use the current one, and that's not something most end users do.

There are a few other things I have my fingers in. I'm still mucking with Android and my wife gave me the idea to build puzzle games. I think that's a great mobile app, something you can do while waiting for your next flight, or what have you. I'm still following native development for Android and plan to write a plug-in that automates the project conversion step to add CDT capabilities to Android projects.

I am also taking a look at Moblin. I bought a Dell Mini 10 and installed Moblin on it. It gives me another native platform that's actually GNU/Linux (Android is just Linux, BTW) to understand better how to use the CDT with it. That feeds into my technical focus on the CDT which will be on build. But I need to get out of the product release crunch before I get further with that.

I also am trying to find some time to look at a WebKit SWT Browser widget. There has been some work there for the embedded web project, Blinki, and I'd like to see if we can make it more generally available. Everyone who's deployed Eclipse on Linux knows the pain of the ever changing versions of XULrunner. I'm hoping standardizing on WebKit would solve that, but we need to see how well it works first.

Anyway, back to bug fixing.

A Good Leader is a Good Architect

2009-10-08T03:57:00.001+01:00

I've been whining (yeah, that's pretty much the word) a lot recently about the state of contributions to the CDT and about the struggles I face even internally to get more time to spend on open source. I've been pretty frustrated and depressed about that and it's showing in my writing.

But the conference calls we've been holding to plan for CDT 6.1 are definitely a bright spot, and they're something I will get some energy and inspiration from. The gang that is contributing, while generally being individuals instead of the teams of people we had in the past, are really smart and have some great ideas. And that's something we can definitely build upon.

Analyzing my participation in these calls and in my day job at Wind River, I am really coming full circle to something I decided a few years ago around the time the CDT was just starting. I am an architect, not a project manager. I love technology and building things and making them good. With the CDT, the indexer was my main challenge and I had a good team to work with and mentor and at the end of the day, it's really good.

I had the same idea with the build model, but I chose to be a project manager for that portion and not get involved technically. I regret that now since I see a few bad decisions that are leading to the current mass of issues people are having with it on the cdt-dev list. Working with Leo from Intel who was there at the beginning too, we are trying to piece together what we were trying to do and I think if we step back to that time and move forward again, we can straighten things out.

So, I think that's how I get out of my current funk. I plan on doing less project management and do more technical architecture work and lead the CDT that way. The team that we have now are very new and there are others hovering around looking for ways to get started. They could benefit from the experience of the few that are still around from the early days when we had a good vision of what we're trying to achieve. And maybe we can grow some new leaders to help the next generation.

Looking around at projects that are successful, those projects get that way because they are lead by good designers that can communicate well, empathize with the customer, and mentor others to do the same. When you don't have a "Sugar Daddy", as I refer to the companies that invest heavily in open source projects (see Google and IBM), you need to lead in ways that make the open source team successful. And almost always, that means focusing on technology and architecture. A good leader is a good architect. And good leaders make good projects. And good projects attract contributors. And that's the answer to my riddle.

Android Notes and Ideas for Eclipse

2009-10-05T23:58:00.000+01:00

Here's a few notes on things I've been doing with Android. I'm under no delusion that I can actually create an app for Android. My wife wouldn't be too happy if I spend the time it would need. But I am finding that this is a great exercise getting into the mind of a mobile developer and is giving me ideas on how to improve the CDT and the Eclipse platform.

I've been working towards constructing a game engine, something I've always dreamed of doing. I am starting with the physics/collision detection engine and looking to open source for solutions. I started with box2d and wrote a little demo that had 20 "marbles" (ok they look more like squares, but squares are easier to render with OpenGL :) that rolled around the screen as you tilted the phone. Essentially, I configured it to alter the gravity of the "world" to match the orientation of the phone. It's a neat demo and gave me a hint at how to use engine and how much horsepower it needed.

But in the long term, I'd like to support the 3rd dimension (love the Simpsons episode when Homer fell into the 3rd dimension :). There's another open source engine called bullet that does it. Interestingly it's very similar to box2d and maybe a bit more mature. So I ported that and got it working with the marbles demo. I was worried about performance, especially since bullet uses floating point instead of box2d's fixed point and my phone doesn't have hardware float. But it was fine, and it allows me to march ahead with bullet for both 2D and 3D physics.

Now, doing this all in Eclipse using Android's plug-in and the CDT for the native code has been generally a good experience. There are a couple of things that are still needed. One is a way to automate the steps adding the CDT nature and builders to Android. And there are some things that don't work. CDT's scanner discovery, which scans build output looking for include path options, no longer works for my projects since I upgraded to CDT 6.0.1. Setting it up for cross compilers has always been a pain, and now it just seems to not work :(.

The other thing that bugs me now, is something that has always bugged us in the CDT community, and despite raising several bugs, has never been satisfactorily addressed is the Eclipse build system. I've set my Android project to reference the physic engine library project to control the build order. But when I go to clean my Android project, which is small, it cleans the referenced projects too, which aren't so small. What makes it worse is that it kicks a rebuild right away so you can't just clean your project and leave it that way.

Hopefully with the new openness shown by the platform team we can get something done there. But we're all a little jaded from the history and we need to overcome that first.

No where's that open source hat?

2009-10-04T22:10:00.001+01:00

One of the points from my EclipseCon talk on building communities was "Wear two hats." Essentially, to successfully attract new contributions, you have to show that you are working in the best interest of the project as a whole. Of course, you also need to make sure the project is meeting the commercial needs of the vendor you work for or else that might not last long.

This is something I've done always in my life at Eclipse. At times, I may have been too much with the open source hat and not enough commercial, but I always had a team with me to compensate for that so it worked out. I do believe that has been one of the main reasons the CDT project has been so successful growing a diverse community.

But as the CDT matures and the vendors who have made big investments in CDT reduce that investment to allow their developers to work on other things that are more important now, I get worried about how we're going to finish off things off. The CDT build system still needs a lot of work to undo and clean up some of the architectural decisions of the past. There are a few guys interested in helping, but these guys are just part-timers, not the dedicate investment we need to be successful.

All I have to hope on is that vendors will put on their open source hat and work for the common good. In theory, working with other such vendors to build a kick-ass build system would help them in the long run and should be cheaper, since they are benefiting from the investment from the other vendors.

But "theory" isn't a place we all live in and few vendors have the vision and long term planning to see that formula work. In fact, what makes it worse, is that vendors tend to see their "improvements" over base Eclipse functionality as a competitive advantage over the free Eclipse. And, trust me, I have seen first hand the view that the freely available Eclipse eats at the bottom line. And there is some validity in that since you can't charge the premiums for development tools that you used to, or so customers believe anyway.

It was a lot easier in the early days of Eclipse when everything was new and everyone needed development tools, especially on the C/C++ space. The vendors that kicked off the CDT found it easy to wear the open source hat because they really needed the help. Everyone fears the elephant in the room, so don't be one.

But now that the development tools are "good enough" the investment is no longer there to take it to the next level to make them "best in class". And as much as users of the free Eclipse see the deficiencies and raise bugzillas to have those deficiencies fixed, I have to feel for them.

As long as Eclipse is staffed solely by vendors making money on Eclipse-base product, the free one isn't going to be great. Now, also in that magical place called "theory", an Eclipse.com funded to do development would help as much as Mozilla.com helps Firefox. But it doesn't work that way in the Eclipse ecosystem and that makes the poor project lead who likes to wear the open source hat wonder whether it's worth it anymore.

Remember PluginFest?

2009-09-28T16:36:00.001+01:00

It's been a while since it was held. The Eclipse PluginFest was a really cool event organized by Ian Skerrett and hosted by the folks at Symbian in London. It was part marketing event and part engineering event intended to show how off the promise of Eclipse as a platform by doing some interoperability testing between the different products, focusing at the time on the embedded/mobile market. For the most part, it was a success, especially for tools up the stack like analysis and modeling tools.

But one thing that was clear then and is still true today is that plug-ins from platform providers, generally vendors that provide tools for building applications and customizations for their operating systems, don't mix. In fact most of them assume that you are not building for other platforms and many of them have their own version of the Eclipse platform.

But as I take a look at the mobile space, it is clear that an application developer if they want to hit the largest possible market, are going to have to target multiple platforms. I don't see one winner taking hold yet. iPhone is in the lead, but Android is making progress, and the others are hungry for a piece of the pie.

The question is who owns that problem? I looks to me, anyway, that the platform vendors are actually more interested in locking developers into their platforms. That is most obvious with iPhone and the fact you can only use Macs as development hosts. The Android plug-in assumes you are using Eclipse only for Android development, breaking a number of UI guidelines along the way (I don't want to hear from it if my current workspace has no Android content, damn SDK location dialog, grrr).

I have no answers. My hope is that the newly renamed Sequoyah project looking at tools for mobile can be a focal point. That will require more vendors to participate in it. I think it'll also require the developer community to stand up and demand more from the vendors and maybe Sequoyah would be a good venue for that. At the end of the day, who is looking out for the poor app developer who needs to deal with all this?

Phone Games To Hurt Console Market?

2009-09-27T05:39:00.000+01:00

Just read the NY Times article here that claims Apple is casting a shadow over the console game market. Of the 758 games shown at this week's Tokyo Game Show, 168 were cell phone games. That's a big number. I'm not sure if the premise is true, but it does open your eyes to a change that is underfoot.

And I think that's were my excitement over the mobile software space is coming from. These cell phones, like my personal HTC Dream Android phone, are decent little gaming machines. Now you aren't going to play first person shooters like I was earlier today with Halo 3 ODST, but for casual gamers they're a hit. And we see it today with the iPhone. When someone shows me their iPhone, it's usually to show off a game running on it.

Android has some growing to do to be a good software platform for mobile games. Good games need to get all the horsepower they can out of the phone without draining the battery, i.e. you need to write as much code to run natively as you can. Until Android gets support for OpenGL and other platform libraries needed to make games into their NDK, gaming on Android will be on a slow growth curve. But once it's there, watch out.

The new platform that caught my eye this week was Moblin, and not just because Intel owns Wind River (my employer). There was a big teaser announcement on Moblin, which until now was a netbook OS, being ported to run on Atom-based phones of the future. Taking a deeper look, I was pleased to see that Moblin really is a Linux "standard" distro with all the gaming libs you need, like OpenGL, gstreamer for audio, SDL for IO, that you get on a desktop Linux distro. I can't wait to see Atom in a phone and see how it compares to the iPhone and Android platforms of the day.

As I keep mentioning here in this blog, it's a great time to be a programmer if you get into the mobile space. There's so much innovation there, and so much opportunity to create something new. And being a non-traditional environment, it's a great place for Eclipse based tools to become the defacto standard, especially the CDT with it's flexible toolchain support and all around IDE goodness. There is activity going on in the community to bring that goodness to these platforms and I can't wait to try them out.

CDT 6.1, We're not done yet!

2009-09-24T17:03:00.001+01:00

We had a couple of really good planning sessions so far this September as we put our plans together for the next release of the CDT, CDT 6.1 for Helios. We've been focused on Build and Debug. We'll continue to move the sticks forward for the editor and parser based features, but build and debug still have some major work to do.

On the build side, we're focused on improving the CDT Scanner Discovery mechanism that scans build output to try and figure out the include paths and defines that you are using for your build. That information is fed to CDT's parser to replicate the parse your compiler does. And that gives us pretty good accuracy to enable things like open declaration and content assist. This work will be a big challenge as we have a bit of a rag-tag group of part timers to try and get this problem area for CDT integrators and users fixed up. But it's a great challenge for me as a project lead to see if we can get as much done as we can.

On the debug side, there's some exciting news. As Ken Ryall from Nokia has been blogging lately, they've been working on a new debugger that's much more tightly integrated with the CDT, and they're ready to contribute it. Essentially, it's a replacement for gdb. Now you can argue whether that's a good thing or a bad thing, but I think it's a good opportunity to improve CDT's debug ability. And of course, it'll be able to sit along side our gdb support which continues to be important for a number of vendors.

But part of Nokia's work that has me most excited, is the native Windows debug support. This is an important step towards finally getting a complete Visual C++ integration for the CDT. I have a build integration almost ready to go. All that was left was debug support. While it is still missing support for Visual C++, Nokia's Windows debug API support gets us maybe half of the way there.

The other good thing about Nokia's work is support for gdbserver as the small agent that does the bit twiddling. Those who've done embedded development know about gdbserver as that's how you do remote debugging of targets using gdb. Reusing gdbserver gives Nokia's work a huge leg up for embedded developers working on all platforms that support gdbserver.

So despite being 7 years into our program, there is still work to be done on CDT. The community is still vibrant. We don't have the big vendor contributions like we used to, other than Nokia of course, but there is still a lot of work to be done and individuals and smaller vendors who are interested in helping. So to quote Monty Python, we're not dead yet :).

Eclipse Tools for Mobile Needs Some Buzz

2009-09-21T20:39:00.000+01:00

I attended my first Sequoyah (Eclipse tools for mobile, except J2ME, but that's another story) meeting today. Why am I? Well I'm getting more and more into mobile app development in my hobby time, at least for Android anyway, and I'm turning that into a personal focus on better support in CDT for mobile application development. We can then make this available for platform vendors who want to better support developers making applications for their platforms.

My plan is to start by building a set of plug-ins that automate at least the build setup for Android JNI development. Debug is another story and maybe someone else can help with that. And we can look at what's needed for other open source mobile platforms down the road as well. And maybe some other vendor will come along and help out.

But, as I dig into what's happening with mobile at Eclipse, I'm a bit surprised, and disappointed, about how little there actually is. Motorola is putting forth a great effort and contributed a significant amount. As with most vendors (almost all) that contribute to Eclipse it is mainly focused on their own commercial needs. But they also don't seem to be getting much help from anyone else. It takes multiple companies to make a platform and it's sad to see that isn't really happening, despite all the marketing buzz surrounding Pulsar.

And I was also saddened to see Craig Setera's blog for help for the Mobile Tools for Java project. MTJ is probably the project hardest hit from vendors coming and going that I've seen. And after the push to get Craig's EclipseME project merged in for the reboot, I was hoping for greater things there.

On the Sequoyah call, I was asked for advice on how we could solve these things. Man, it's tough. You really need a community, and in particular, a vendor community, that has a vested interest in contributing. We had it easy with the CDT. Everyone needed an extensible C/C++ IDE and it made business sense to invest a person or two to help make it happen. I had it pretty easy as a project lead, and I feel for Craig and the Motorola gang as they try to get this thing going.

The only thing I can come up with is a trick I used in the "dark" days of the CDT after my team at IBM were reallocated. "Create the need". Find something that vendors will see the need to invest in. Usually, this is in the form of some platform piece that they know they need and that multiple vendors can work on, and then show that not enough people are working on it so it's going to suck in their product too.

I'm not sure that's going to work here since there seems to be a huge hesitation to make contributions from the vendors who could be contributing. But that was true with the CDT in the early days too. It was the QNX+Rational show for quite a while until Intel and TI broke the ice.

At any rate, I'm posting this as an attempt to help Eric C out. I'd really like to see Sequoyah succeed and for us to have a nice set of platforms and examplary tools for mobile app development at Eclipse. But that won't happen without growing the community and we'd certainly be interested in your thoughts on how we can make that happen.

Apple leading the way in multi-core programming?

2009-09-18T20:04:00.001+01:00

One of my pet study areas is programming paradigms, something I've done since my university days looking at SmallTalk (object-orientation) and Ada (safety critical). The next great next battle line is how to take advantage of multi-core machines to do parallel computing without blowing our poor programmer minds. Intel is doing a lot of work in this area and it's really interesting that Apple is doing the same. I'm not sure why, but good on them.

The two technologies that seem to have sprouted from them and are supported in Snow Leopard are OpenCL, the Khronos standard for mixed GPU/CPU computing, and Apple's Grand Central Dispatch, a task parallelism extension to C, C++, and Objective-C with something called Blocks. There is a recent report from Hardmac.com that shows some real significant improvement form these technologies.

I don't know much about either, but this is definitely something I'm adding to my reading list for those nights I can't get to sleep (which if you're following me on twitter you'll notice are happen regularly).

State of the Doug

2009-09-12T19:30:00.001+01:00

I've been tweeting a lot, but tweets tend to be temporal things that disappear after a short time, so I figured I should blog some of those things. Assuming anyone really cares, but that's part of the mystique and something I call the "cricket factor", when you tweet or blog, and no one's listening, and all you hear back are crickets in the night. But anyway, here's what I'm up to lately.

I made quite a splash recently stating my frank opinion on e4. I had lots of good feedback on that and I pissed off a few people. But I met my objective of making people think about it. To summarize, I worry about the stability of the platform and how e4 will impact the hugely understaffed projects up the stack. And I don't like RAP. If you're running web apps, follow the investment in JavaScript engines and put your UI code in the browser. Which also means I don't care much about the e4 UI work either. But as one e4 committer mentioned to me, "it's fun". I'm sure it is.

As cool and interesting my investigation into GWT has been, I barely get a day a week to do open source work and I still have a couple of things I want to do with the CDT, i.e., help clean up the build system, and support JNI debugging. And I want to spend my hobby time on other things. So enough of that. A lot of people get GWT and how it works well with Equinox, so it'll live on without me.

As for my hobby time, I am getting more and more pumped by what's happening in the Android space. So I'm turning back to that and hope to feed my curiosity on game development by making games for Android. Not sure I'll ever get far enough along to get something on the Android Market, but it'll make a good winter activity. And who knows, maybe we'll see Android running natively on Intel chips some day.

So that's where I am. I have way more ideas than time to work on them having a family and all. But I'll continue to blog and tweet things as they come to me, at least as they relate to open source, and maybe that will help others, or maybe it'll just feed the crickets.

Using CDT for Android Native

2009-09-10T03:37:00.000+01:00

Android has a native development kit (NDK) which can be used to create JNI native code for Android applications. In this video, I show how I convert an Android project in Eclipse to add the C/C++ nature to it and set it up to build the shared library that gets included in your Android apk file. This gives you all the power of the CDT in combination with the JDT to build Android apps with native code. Except for debug, though, as JNI debug remains the lost holy grail for the CDT...

If you want to look at the code from the demo, you can clone or download from http://github.com/dschaefer/androidDemo.

Link to YouTube

Time to break down the Silos between the *DT's?

2009-08-31T17:06:00.002+01:00

What started out as a personal need for writing and debugging JNI-based applications, both based on Eclipse and for Android, has turned into something bigger, a lot bigger. The hardest problem we face for what I'm doing is supporting multiple debugger technologies in the same debug session and ensuring a nice seamless experience. Showing both Java and C/C++ stacks merged together and stepping back and forth between them would be the cat's meow.

As I'm starting to hear from the greater Eclipse community, there is need for cross language/cross technology debugging in other areas as well. One example is Rhino which is being used by the e4 team to support writing plugins in JavaScript. Having a debug session with JavaScript and Java in the same stack would also be awesome. Similarly, we have JavaScript or ActionScript running in the browser interacting with a Equinox server, or maybe PHP running in Apache. Web applications are the manifestation of distributed applications and, as promised, those applications tend to involve multiple languages.

Traditionally, the language tooling projects at Eclipse have lived in silos. The CDT team has have very little interaction with the JDT team, for example. And that's not generally the fault of the team members. It's just a symptom of the lack of investment in Eclipse towards common technologies. Being an engineer, I have no idea how to solve that except to ineffectively whine about it. ;)

But one objective we've had with the CDT was to ensure that the C wasn't just for C/C++. Many of our frameworks are language independent as much as we practically could. We haven't had enough investment to be able to push that out to the general Eclipse community, but we do have projects like Photran (Fortran) and the fledgling Hibachi (Ada) and the new but remote ObjectivEclipse (Objective-C) doing that.

I think in particular, our new debug framework, DSF, could be used for much more than C and related languages. DSF started out as a solution for the difficult debug environments we face in the embedded space and actually started as the Device Debug project of DSDP. We've migrated it down into the CDT in 6.0. We've often quipped that it really should be down in the Eclipse platform itself. There will be challenges, technically and otherwise, to make that happen.

What I want to do is start prototyping multi-language, multi-debugger debug sessions based on DSF. That would initially include Java and C/C++. I'll also take a peak at JavaScript debugging and consider how that impacts it. I'm confident the flexibility we brought with DSF can be leveraged to make the Eclipse side of this relatively straightforward. The bigger challenge will be co-ordinating the different debuggers.

If others are interested in this work, we should co-ordinate our efforts. Let me know and we could set up a mailing list to talk about this area, and hopefully we can start breaking down the silos.

Using Git GUI with Eclipse

2009-08-30T06:38:00.001+01:00

Here's my next set of screencasts showing how I use git and git gui in particular with my Eclipse projects. There are two parts. The first shows how to set up a workspace based on a git clone repository, i.e. copying a remote repository to your local machine and setting up an Eclipse workspace for that repository. The second part is how I commit and push my changes to the remote server as I develop code. Hope this is useful.

BTW, This is best viewed by clicking on the YouTube link and watching it full screen in HD mode.

Part 1 - Creating your Workspace

Link to YouTube

Part 2 - Committing and pushing a code change

Link to YouTube

The JNI Debug Problem

2009-08-26T03:04:00.002+01:00

One thing I noticed the other day was that I'm doing a lot of JNI coding lately. In our Wind River Installer, based on p2 BTW, I have native code for doing a few things like compression and getting at the Windows registry. The CDT has native code for doing advanced process management, and getting at the Windows registry. I've played with Android native development which is all based on JNI. And I was thinking of hooking up the ALSA library to do Audio management with my prototype "Eclipse OS". That's a lot of Java/C coding. And, unfortunately, all without a debug solution :(.

JNI debugging was one of the early goals of the CDT. Unfortunately, it has never really materialized, at least not generically in a way we could incorporate into Eclipse. And given that I see a strong symbiotic relationship between Java and C/C++, I am getting more motivated to tackle this problem and see if we couldn't come up with a solution that we can integrate into the JDT and CDT (or maybe just the CDT).

But the first thing you run into when looking at the code, where do you start? I'd like to be able to step into native methods, hit breakpoints in native code and see up the stack all the way into the Java stack. And really have an integrated debug experience where you don't have to do much of a paradigm shift when going between the two worlds. And given the way the Debug platform is structured, that should be possible.

So there's different ways to slice the cat (not that I slice cats, I like cats). You could add an extension point to be able to plug in native handling into the JDT debugger. I'm not sure what the JDT gang feel of that, or whether they've hopefully thought of that. Another solution would be to build a new Eclipse Java debugger component, but base it on CDT's Debug Services Framework. That may make a more natural solution, but I fear it would be a lot of work and it would take a lot of investment to reach parity with JDT's debug solution.

I'd like to hear what the community thinks. What is the right solution. Hopefully we can come together, find the development resources, and finally reach this Holy Grail for the CDT.

What could an Eclipse OS be?

2009-08-24T01:27:00.001+01:00

I got some really positive feedback on my quick little demo of the "Eclipse OS" prototype that I've started building. So I've started to capture ideas on the github wiki for the repository that I created there. Feel free to add your thoughts there, or here. Maybe if there's enough interest we could grow a little community around the idea. If not, that's fine too. I'm really just exploring a role Eclipse technologies could play in a browser based "OS" such as the announced Google Chrome OS.

Here's the link to the wiki and here is what I've started with: http://wiki.github.com/dschaefer/eclipseos

What should the Eclipse OS be? Take one of those new fancy 10" netbooks. Install enough Fedora to xinit the Google Chrome browser with the Flash plugin (necessary in my books for a full web experience) and launch an Equinox standalone server. What local web applications would you need to manage your netbook? Feel free to add to this list.

Power Off. To shutdown the OS and power down, i.e. run the poweroff command. (Update: this is the first app and is now working).
Install Manager. To install new web apps into the server using p2. Integrate p2 with yum to install native components that the web apps may need.
Audio Manager. Similar to ALSA mixer but as a web app. To control the volume of the audio in the least. This could be a good first test of writing native code to help implement the service.
File Manager. To look at and manipulate the files on the system, maybe even open them in the browser.
Connectivity Manager. To manage wireless and wired network connections.
Power Manager. To manage power saving modes.
Office “Suite”. To prepare documentation and presentations while disconnected, like on long flights.
E-mail. For those who would like offline access to e-mail.
An IDE so I can build my web apps locally (thus the connection with my Web IDE (W-IDE) prototype).

Screencast Test

2009-08-19T18:42:00.006+01:00

After asking around twitter, I had a number of people recommend TechSmith's Jing for doing screencasts. These are the same guys that do the masterful Camtasia which is a more full featured, i.e. expensive, solution. Jing does a good job at capturing my screen and audio. It's limited to 5 minute videos, but give that my main purpose is to share quick ideas with my blog readers, I think that's fine.

So here's my first screencast test. I'm showing the current state of my "Eclipse OS", i.e. Fedora minimal install + X + Chrome Browser + OpenJDK + a standalone Equinox app server. There's not much new here. But I'm really just learning how to use this media. One thing I learned as you'll hear half way through, is that my laptop fan kicks in. Drives me nuts, but anyway. Expect a lot more of these in the upcoming weeks. And hopefully, I'll improve the quality as I go to (like talking louder :).

Update: uploaded to Youtube which gives a much better viewing experience, especially in fullscreen mode.

Update 2: Planet Eclipse seems to filter out the embed object. Click on the title to come to blogger to see the real thing.

Eclipse OS?

2009-08-15T04:21:00.004+01:00

I left a pretty cryptic entry last time. Essentially, I am trying see how easy it is to build a Chrome OS using Fedora as a base. It was pretty easy, and I have the instructions on how to do it. I'm going to put together a series of Jing screencasts (my new favorite screencasting tool), to show you how. That'll take a few days to get together, especially given the beautiful weather we're finally getting here in Ottawa.

But I wanted to show you a screenshot of the final result. Because, not only am I doing a Chrome OS look-a-like thing, I'm also putting Fedora's OpenJDK and an Equinox server application on it to run applications locally. In this case, it's the GWT Greetings app that you get when you create a new GWT project in Eclipse.

As I mentioned when I first heard of Chrome OS that it would be great if we could put Equinox on there to run local apps. Now I have a chance to expand on that idea and see whether it makes sense. Once I get the instructions together you can try it to. Could this be a start of an Eclipse OS?

Chrome OS Preview?

2009-08-14T03:21:00.003+01:00

I'll be posting more on this later, especially how you can do it yourself. But I've built what could be the upcoming Chrome OS. I did it starting from the Fedora 11 net install and added what I needed, which wasn't much. Here's a teaser screenshot until I can firm up the recipe :)

Web apps make me think MVC

2009-08-10T04:13:00.007+01:00

I'm blogging more than I'm coding lately, so I'll try to keep this brief. But I noticed someone mention MVC while I was googling around for practical information on GWT. After I thought about it a while, building a web app is a great example of the Model-View-Controller paradigm.

The model is data you store or derive on the server. You can use GWT's RPC mechanism to get at this data. The Controller is also on the server. You can send commands, like build my project, to it via GWT RPC too. The server may then farm that out to other specialized servers to actually perform the action. The View is the JavaScript code running in your browser that takes the data and draws it using GWT's widgets and invokes the control using GWT's Handler mechanisms. Having a well defined RPC mechanism, and having a requirement to reduce the traffic over the wire to help with responsiveness, you get pushed to keep your web app MVC clean.

Now, relating this back to my mobile app interests, I can easily see the View portion of the app being replaced by the native widget framework for the particular platform. As I've mentioned in previous posts, I don't think running a web app in a browser in a smartphone is a good idea. I know the browser on my Android phone is really slow. You're better off using Android's native widget set in Java to accommodate the form factor. That's what mobile app building is all about. What I need now is an implementation of GWT's RPC mechanism in Java using Android's communication APIs, and really interesting things jump into mind.

What this leads you to is having three View implementations for my web-based IDE, that I'm now calling W-IDE. One in the web browser using full GWT, one in Android using Android's native widgets but still communicating with the services defined in GWT, and one using the regular Eclipse desktop UI, theoretically using those services as well.

Now, yes, that's three implementations of the same thing, and I know how that rubs people the wrong way. But my theory is that they are, in fact, not the same thing. Depending on which of the three you have, you are likely to need different workflows. Running Eclipse in a 24" monitor, it's OK to have all those views and taskbars and such visible all at once. In a browser running in a 10" netbook, not so much, and you'd really like to make it page based to take advantage of the browser's history mechanism. And in a 4" smartphone, I really struggle with any workflows that make sense, but they certainly would be limited to one view or editor at a time.

At any rate, this is sure turning into an interesting journey of exploration. In the end, we may decide that this is all crap and IDEs are meant to run on desktops only and that using RAP's server-centric architecture is OK to render in the browser (which if you can't tell yet, I'm not sure I agree with). But this is a 5 year journey and we have time for the different technologies involved to mature and we'll see. I think we have a lot of time to figure this out.

And, yeah, I guess I failed at keeping this short.

Are we de-evolving or on a natural evolution?

2009-08-07T02:44:00.008+01:00

Talking around the office about a future with web-based IDEs, it was interesting that people are starting to get it, or at least, not scoff that it's something we'll ever to deal with. There are some good aspects to it for the tools business. At the least it's a great way to quickly get our products out to customers with minimal install fuss (the bane of my existence these days at work), and it's a great way to get immediate feedback on what they find valuable.

The question that needs to be answered is why now? I remember back in the 90's we were clamoring to get away from the client/server model. Everyone wanted a PC or workstation on their desk and former stars of the server world, DEC in particular comes to mind, faded away. Servers found a new life thanks to the web and it seems now, about 20 years later, we starting to climb back onto the client/server bandwagon. Why did we get away from that architecture and what's happening to make us want to go back.

From what I know, looking back, I think one of the biggest problems with servers in the 80's and early 90's was their sheer cost. They were expensive machines. You could buy 100 PCs for the cost of one of these things. Worse, yet, they didn't provide 100 times the compute power. The price/performance ratio made PCs a smart bet. They are both cheep and powerful. That, and they provided freedom to the user. If the server went down, they could keep working, and if they wanted to install some "forbidden" software, they could do it. It was really refreshing come to think of it.

But as any IT professional, or installer guy, would tell you, maintenance of all these machines is a nightmare, for the admin, and for the bottom line. As employees of larger companies well know, there are companies making money on software that beaver away in the background making sure all the other software is kept up-to-date and on the up-and-up. And, of course, some of the more rogue employees know how to uninstall that software and get it out of the way ;).

What the old server model provided was that ease of maintenance. You installed software on one machine and all your users had instant access to it. Of course there are risks to that as all of us tweeters had to deal with today, but with an improved focus on security and robustness with these critical server apps, like we had in the server era, those should become rare.

That, and looking at the cost of servers these days, the costs are way down. I would think that the price/performance curve is turning towards the server side. And just look around your workplace and count the number of CPUs sitting idly. It would be an interesting study to figure out what percentage of CPU power companies have is actually being used. It might make more sense to spend more on servers and less on desktops. You don't need that much power to run a web browser, especially with the ever improving JavaScript VMs that we are finding in them these days.

It's not really far fetched today to see a future, say five years away, where all of our apps are running on servers, in the "cloud" say, and we are accessing them through "dumb" terminals running web browsers, which is what Google's Chrome OS and I'm sure others will provide. The economics are right. The culture though is something else. Are users ready to give up the freedom that traditional desktops provide? I think so, but only if the applications provide significant new value. Tools that integrate with other web apps to allow collaboration over the web could provide that value. Running desktop-style apps that simply display themselves in a web browser, will not.

Time to come clean. I'm a Google fan-boy

2009-07-31T03:15:00.005+01:00

I appreciate all the comments on my last blog or two about how e4 is doing a lot of the things I am trying with GWT. I don't dispute that. It's even interesting that RAP is planning to build on top of GWT. That's fine. I respect what the e4 guys are doing, it's a huge task and they are trying to modernize Eclipse as we all agree is necessary.

But I'm just wondering if using GWT directly while using OSGi web services to hook up to the IDE things I need in Eclipse, which is essentially IResource and up, is a better architecture to get us to a web-based IDE. And right now I'm trying to keep it simple and avoid any layers on top that e4 may be providing. Maybe there's a compromise choice. And I'll be open to that once I fail, which will not surprise me in the least. But I need to see first hand at what's possible in the GWT world. In the short term, that probably means I will appear to be anti-e4. But I'm used to being the bad cop by now, I guess.

So why am I doing this? OK. I admit it. While I have no contractual relationship with Google, I am a Google fan-boy. I have an Android phone which I am learning how to build apps for. The Android momentum will be unquestionable over the next few months as new handsets land like the rain in Ottawa this summer, including ones from our Eclipse friends at Motorola. Chrome is my default browser, although I'm using IE8 on my 64-bit Windows 7 laptop to check out its progress (which is actually impressive). I'll go back to Chrome once I get the RTM build installed. I use Google Mail for my Eclipse mails and am finding it nicer to use than the Outlook I use in my day job and I can access it anytime, anywhere, especially on my Android phone.

Google Wave and Chrome OS are technologies I am very excited about, and I have no doubt they will have a dramatic impact on our industry. And it's Google Wave that I have an eye on for this IDE work. That is my end goal. I believe following Google's way of doing things is important in that journey. And while not all Google products use GWT, Wave does, and it was the excitement for GWT I heard in the Wave lead's keynote at Google I/O which has driven me here.

And maybe that makes me the Google fan boy at Eclipse, so be it. You wouldn't bet against Microsoft in the last decade or so. I don't think you should be betting against Google now. And while the relationship is good on the tools side, I want to help make sure Eclipse isn't on the outside looking in when it comes to these run-time technologies.

GWT + Server-side Eclipse = W-IDE

2009-07-30T16:11:00.002+01:00

Someone once asked me why we break up things between ui plug-ins and core plug-ins. My theory was that we could eventually swap out the ui with something else. I didn't really believe that at the time, and I'm not sure how well architected our CDT plug-ins are to allow that, but it sounded good.

So as I begin my journey down the road of web-based IDE's it really struck me that this was the time to swap out the UI. My theory goes like this. Google are the experts at creating web applications (and you may disagree with that, but stick with me). They have a framework for building them called the Google Web Tooklit, GWT, which allows you to program your UI in Java which then gets compiled into JavaScript. And, they have a really cool RPC mechanism, again all in Java, that overlays Servlets. Hey, Equinox plus Jetty gives you Servlets. Why not swap out the Eclipse UI code with a GWT implementation that talks to our Core code using Servlets?

A big thanks goes out to Ian Bull who reminded me of the example project he created last year that shows how to use GWT with Equinox OSGi. I have extended that a little to call into the Eclipse workbench, right now calling Platform.getOS(). This is the start of my prototype web-based IDE using GWT as a front end to the Eclipse IDE Core parts. And I am pumped the deeper I get into it. Feel free to follow along as I check my prototype into http://github.com/dschaefer/w-ide. Feel free to fork that and join in the fun. (BWT, I need to show you the cool way I'm using git, stay tuned).

As Ian says, "GWT + OSGi is a great platform!" And I am starting to see why. It really is. So much so that it confirms my earlier conjecture that Equinox would be a great addition to Chrome OS and I hope Eclipse people are talking to Google people about that. Wouldn't it be cool to see Equinox serving up local server pages, presenting a p2 install web UI to download and install bundles into your favorite mobile device. Yes, it would be cool.

Oh, yeah, and here's my vision

2009-07-25T02:48:00.004+01:00

Ian pointed out that I actually didn't state what my vision for Eclipse was. I noticed that after I posted, it was probably the wrong title for what I ended up writing. I'll try again, maybe sooner than later, I'll actually get my point across.

I do have a vision for Eclipse, or rather, Eclipse as an IDE. Eclipse is so much more these days, I really need to differentiate myself. I am an IDE guy. Eclipse started as an IDE, turned into a great IDE, let's keep it that way. Maybe that's my vision. Keep a good thing going with focus on stability and quality.

I also have a vision on where IDEs are going, and I mentioned that in a previous blog where I stated the prediction that the desire for software developers to write software using mobile devices will drive that vision. But in the end, I think it's more than that.

This vision comes from watching the Google I/O keynote on Google Wave. If you haven't seen it yet, do so. Whether Google Wave is the right technology or not, the workflows they present are the future. I have no doubt of that. And it's all about collaboration, including real-time collaboration, through your web browser. And that let's it run on any platform with a web browser, which is pretty much everything.

I was especially struck with the demo of the team working and commenting on documents. Everything becomes a document, or a Wave in Google's terminology, and everyone can contribute to it. And it keeps track of who contribute what and when.

The first thing that popped into my mind, being the IDE guy, what if the document was a source file? Wouldn't it be cool to post a source file for review, have people attach comments to it, maybe even edit it to propose changes, maybe even work on it together live? Pair programming accross the internet? Doesn't that make sense in the global world we live in with software teams spread accross the world? Working in the same environment I do other collaboration. A bugzilla front end in Wave is a natural, integrated with my source in Wave, a truely integrated development environment?

Given that as a vision for IDEs of the not so far away future, how does Eclipse fit in. We have so much invested in making Eclipse a good IDE, I'd hope to keep as much as I can. And I think we can, removing the UI front end, which would be handled in Wave, and providing services that provide access to all the good information that our indexers and such provide. Even providing access to remote build and test machines to complete the edit, build, debug cycle. I think there's a significant role for Eclipse there, and thanks to Jetty and the HTTP Equinox/OSGi service, we could do that today.

So that's my vision, long and short. In the short term, though, I need to keep customers happy and try and convince new customers that Eclipse is right for them. And that's where stability and quality are criticial. And that's where I'm coming from. I'm Walt Mossberg, uh never mind :).

What is the Vision for Eclipse?

2009-07-24T22:16:00.004+01:00

I'm on vacation, it's rainy, so I might as well write and maybe provide a little more insight into my thinking on e4.

Now, to start, I must first apologize for the tactless way of bringing this up as I did. As the title stated and I tried to reiterate throughout the entry, these are my fears for how the CDT fits in with e4. Nothing more, nothing less, and certainly not meant as a personal attack on anyone working on e4 (and no, despite common belief, I don't work on e4). It was really targeted at those outside the e4 community to take some time and understand how e4 impacts them.

I've sent a request for feedback to the cdt-dev list, so if you're there or even if you're not, please send me a response. I really want to know what the needs of the CDT community are so that I can properly feed them to the e4 team. The feedback I have so far, and so far it's been private, but that's OK, is that e4 is OK if we don't have to do anything significant to adopt it. Which then brings up the point of why adopt it if we're not going to take advantage of any of it. The other feedback that I got is that e4 isn't solving problems that our community has. Hopefully I'll get some more information. But, so far, it does justify asking the question and justify my fears.

My biggest fear for Eclipse is apathy. We're all working on our projects and being successful at it. As I said, I'm a happy user of the Eclipse SDK and CDT, especially with the new CDT 6.0. And I'm bragging about it to the Android NDK community as we speak. I know a lot of people question e4. I just happened to be dumb enough to blog it out loud.

My Biggest Fear for e4

2009-07-23T18:39:00.004+01:00

A buddy of mine noticed that I don't get as many comments on my blog as I used to. He thought it was because I wasn't being controversial enough. He's probably right. Most of my readers follow this on Planet Eclipse and I haven't really commented on that much lately other than the great fun I'm having using it for my Wind River Installer work and for Android native development in my hobby time. I'm just a happy user now, I guess.

"Linus is a wise man"

Following Ian Skarrett on Twitter, he points us at an article in Linux magazine where they discuss Microsoft's Linux driver patch that I'm sure you all heard about. They quoted Linus, who is indeed a wise man with a cool head. He's just happy to get a contribution from a new member of the community and doesn't care who it is. That's certainly one of the big factors to the CDT's success as hard nose competitors worked together peacefully. It's the only way to be successful. Don't let emotions cloud your judgement.

Selfish need drives contributions

The other thing that Linus pointed out was that "I agree that it’s driven by selfish reasons, but that’s how all open source code gets written! We all scratch our own itches". He's bang on there. All of the vendors I work with on the CDT are contributing to it to make their products better. I'm sure that's true for many open source projects. For the most part that's a good thing, since open source users get the benefits of that work. But it also means, if there is a feature you need that none of the vendors do, you aren't going to get it. And as much as we beg people to contribute, it rarely happens. ~350,000 open source CDT users, ~3 contributors, that's pretty rare.

What does this mean for e4?

Well as much whining as the CDT community has done over the constraints we have to deal with via the IResource system, we only got one contributor to the e4 flexible resources project. And even there, the changes being done should end up in the 3.x series and isn't a major break from current system. So I can only assume that vendors are dealing with what they have and the need isn't really there for them. But I do know there are some big open source users who need it. Time will tell if they are big enough to invest in it.

But my biggest fear is the rest of e4. There are some pretty major changes in it. Will the contributor community feel the need to adopt it? And what do you do when certain vendors don't want to adopt it? What do we do with the CDT if none of the vendors step up to support e4? Stay on e3? What if Mylyn decides to support e4 and drop e3? What if we're forced to adopt e4 if the rug gets pulled out from under us on e3? And don't let backwards compatibility fool you, there is a massive verification activity in the least to make sure old plugins work on the new platform.

My big fear

I've stated this before, and it remains true today. We're headed into uncharted waters with e4. I fear that the contributing vendors to the CDT will not put the effort into supporting e4, because they don't have the need. And I think this is too big to artificially "create the need". Eclipse can't afford two platforms. Yet that's what we seem destined to have. A lot of CDT vendors consider the CDT finished. We have very few new features on the horizon. That will likely mean less contributions. How are we supposed to pull off adopting a new platform? That's my biggest fear.

Project Navigator: Apologies to all

2009-07-22T02:13:00.002+01:00

I have to apologize to the Platform team and Francis in particular for my earlier complaint about duplicate entries showing up in the Project Navigator. It turns out that the problem was actually all CDT, or more specifically, how I set up the CDT part of my combo JDT/CDT/Android project.

By putting my source and build output into their own subfolders in the the project and setting the C/C++ Paths settings to point to them and not the root Project folder, the CDT stopped trying to display the other folders in the project in the navigator, the JDT folders in particular. No more duplication!

My disappointment has turned into happiness. I can now work on my Java and C++ files using the same perspective. The only thing that still doesn't make sense is the tool bar where the new Class button still depends on the perspective, but that's minor.

I'll have to come up with some way to automate the creation of what I call JNI projects that have the mix of Java and C/C++ so others don't run into the same thing I did. Maybe an improved Convert wizard.

At any rate apologies all around and thanks!

Mobile will drive "IDE in the Cloud"

2009-07-17T02:21:00.009+01:00

I'm in the middle of making some last minute code changes for work before I start my vacation, or staycation as I hear lots of people calling it these days. We have a pretty big JUnit regression suite to test our p2-based installer, and I made the mistake earlier this week of not running it and ended up having to rewrite the algorithm to solve scalability issues. Lesson of the day, don't create too many Java objects in long running native code, Lord knows when they get garbage collected.

This mobile machine's hot, man!

The main reason I didn't run them was because I was working at home with my laptop that day. These long running tests create some massive heat build up in my machine. I lost a hard drive a few years ago doing something like that and it's made me nervous ever since. I really don't think laptops are built to handle the intensive compute and disk workloads that I need as a software developer. I think I'm pushing the envelope too far. In fact, I was going to start this blog while the tests were running earlier this evening but the heat knocked out my wireless.

The ultimate mobile developer platform?

I'm sure you've all been following the Chrome OS "shiny object of the week". The technical details of the OS itself and the supposedly sinister plot by Google behind it aside, there is no doubting that the designs for the upcoming sub-netbook, aka smartbook, machines are pretty exciting. All day battery life, integrated 3G or WiMAX connectivity anywhere, and with big enough screens to actually be useful. And, yeah, looking at the processors that allow you to do that, you aren't running Eclipse and gcc on these things to any great scale. But I'd love to use one of these things around the house or on trips to write code with. Especially if it lets these burn marks on my legs heal ;)

Mobile will drive IDE in the Cloud

So assuming you want to write software using a mobile device, how would you do it? And, you know, after all the naysaying I did about "IDE in the Cloud" at EcilpseCon, I finally get it. Wouldn't it make sense to have a workstation setup where you keep all your development tools and do your builds and run your tests, and then be able to access that all from a web browser anywhere in the world? from any mobile device in the world?

That flexibility will drive demand for this architecture, for similar reasons we used this architecture in the pre 1990's where we used to have dumb terminals connected to powerful DEC VAXen (at least they were powerful for the time). What we're talking about isn't much different than that, only the terminals, i.e. the mobile devices, are a bit smarter. But then the compute servers are probably equivalently faster if not more so.

An opportunity to simplify

And, yes, we do use VNC and other remote desktop protocols and clients to accomplish this today. And maybe you can so something similar in a browser (in fact I know you can, ever see WebHuddle?). But with these things I think you'll run into the screen size issue. Myself and a lot of my Eclipse community colleagues have presented Eclipse on 1024x768 projectors and it's brutal. The IDE just doesn't scale that small to be useful. But this is the screen sizes you have to deal with on mobile devices.

While working through this new architecture and solving that problem, I think it's also a great opportunity to simplify the IDE. New users find Eclipse overwhelming with all the views and toolbar buttons and menus, it's really tough to know what to do next once you fire it up. Being in a browser opens the door to new ways of working. I think we're still trying to figure out how to do content creation via a browser, and from Google Apps and Microsoft's upcoming web-based Office suite, we'll learn a lot and maybe some of these things can be applied to software development.

Is it time for a new platform?

Mobile is driving a lot of change in the software and device world. I really believe the software developer will be able to benefit from it. But I wonder whether the platform we've built with Eclipse is the right vehicle for this. I know the IBM team is scrambling with e4 to address that. But I'd like to see real innovation here, something that breaks away from the old desktop IDE paradigms of the past. Maybe Eclipse's "Black Swan" is out there. If it is, we'll have to make sure we recognize it and welcome it to the community.

Android versus Chrome OS in Netbooks?

2009-07-10T18:55:00.003+01:00

Just a quick one. There were a lot of rumours about Android running on laptops, with Acer especially. Now they're wondering if Chrome OS wills squash those plans. People, Android was never meant to run on netbooks. You are worrying about something that was never going to happen in the first place.

If you ever watch the Android UI presentations at Google IO, they pretty much confirm that. At one point one of the designers commented that Android developers need to deal with screens with more pixels, but to deal with that by checking density, not physical screen size.

All Android apps are being built assuming a 4" screen. It would suck if you try to stretch an android list widget to a 10" netbook screen. Big screens isn't what Android is about.

Update: I just read that Schmidt and friends just mentioned the two projects working closer together in the future. Chrome on Androids Linux/BSD OS but without the Java based UI and the Dalvik VM that drives it makes sense to me.

More Thoughts on Chrome OS

2009-07-10T01:45:00.008+01:00

As quickly as it came, the hype has died down over Google's announced Chrome OS. There hasn't been much to stoke the fire so it's died down naturally. And that's a good thing. There's a lot of lead time to figure out how we all fit into this story, if we want to fit in at all. Here are a couple of more thoughts that came to me as I read all the stories. BTW, it seems some writers have already played with the OS, or they're making a lot of assumptions...

Equinox as a local app server

One of the coolest features of OSGi and the Equinox/Jetty implementation at Eclipse is as an app server. This is something I've always wanted to spend more time with. I don't think Chrome OS will be successful without some means of running local applications and the marriage between Equinox and the Chrome browser is a natural. I'd hope the two of these groups are talking.

GWT or SWT browser edition?

To be honest, I'm a neophite when it comes to what's happing with running Eclipse in browser mode, be it RAP or the new e4 SWT browser stuff. All I've seen are demos that try to make the browser look like a desktop app. I think that's doomed to failure. The more you make it look like a desktop app, the more users are going to expect it to work the same as a desktop app, and that just isn't going to happen.

I'd take this opportunity to reinvent my application's UI, to break away from the paradigms that the desktop has locked us into and to come up with cleaner, more workflow driven UIs. Having good tooling is still a must. The Google Wave guys were quick to pour praise on GWT which they used to build the Wave app. I'd pick that if I were starting down this road.

Is there a role for native in Chrome OS?

Believe or not, I think the answer is yes. We'll I'm sure you believe that I think that but anyway. Chrome supports the NPAPI native plug-in API that was started by Netscape/Mozilla/Firefox and is now supported by WebKit/Chrome/Safari and Opera. If you have the need for a high performance app that does it's own rendering, like a game say, then NPAPI is for you. Google already does this for it's O3D graphic rendering API. You can too.

Now, what you can also do with NPAPI is present your C++ objects for JavaScript scripting in the browser using this interface. Now didn't Dave Thomas say something about C++ and JavaScript being the future in his Eclipse Summit Europe keynote last year?

ARM versus Intel

It's not a secret that Intel has an offer to purchase my employer, Wind River, on the table. That hasn't closed yet. But I have to agree with the analysts who see this will help ARM and it's partners. More interesting, though, is that this will really be the first time that ARM platforms and Intel platforms will be running the exact same software platform. It'll be pretty easy to see who's netbook/smartbook/mobile solutions are better. More importantly, it'll drive both of them to raise the bar, which at the end of the day benefits the consumer like good healthy competition does.

Google Chrome OS

2009-07-08T19:04:00.008+01:00

Google announced it's initiative to build an OS around it's Chrome browser. About time. The idea of having a browser based Linux platform is one of the things that had driven me to play with Linux in the first place. It was clear from the experiments I did that this was easily possible. Webkit with a good JavaScript engine is a great choice for that, which is what Chrome is. I guess it just took Google's might to make it happen.

So why would Google invest in something like the Chrome OS. It's easy, and people have speculated on it for a long time. Google wants you to spend all your time in a browser. Why? Because it changes the game. Commerce has move to the web in droves and Google wants to get you closer to that so it can get it's cut for getting you there. It's been a long time coming and the planets are finally aligning to make it happen.

Firefox could have done the same, but Google has the dough to make something like this happen. Which again calls into question why this couldn't have been done in an open source project to start with. But I fear the Gnome/KDE bun fight has taken the Linux community's focus away from how the desktop is really evolving. Google knows where things are going. It's helping to drive them to begin with.

Will this impact Windows? I don't think so. We're creatures of habit and Windows already has a good browser experience. Will this impact Linux desktop? Probably. At the least it could be a better place to go if all you want to do is get away from Microsoft, which, if you are Joe average consumer, would be the only reason you go to Linux. Mind you this Joe developer is pretty happy on Linux. Even then, I am sceptically waiting to see a good browser based IDE experience.

But is the web ready for this? I'm not sure. A lot of people are saying Google Docs is pretty good. GMail is my e-mail client of choice outside of work. I could IM using the browser I guess. I think Google Wave will shake the cart here providing a slick collaboration environment that redefines all these things, so we'll see. I'm sure once you adopt a browser-based OS you'll find out quickly whether it sucks or not.

So what does this mean for Android? As I've stated here and on Twitter (dougschaefer, BTW), browsing on a 4" screen blows. I really struggle with trying to pan around a web page to find the information I need. This is not to say that web services aren't useful on smartphones, it just that they work much nicer if there is a thicker client to format the data to the platform, and to just manage the data bandwidth better.

Probably the most interesting aspect of this that crossed my mind is that the Palm Pre already is browser based OS. It's also based on Webkit running on a Linux platform. So the real question is - will Google try to get Chrome OS into the smartphone format? I swear the Chrome and the Android guys don't talk to each other. Or this strategy would already be figured out before the announcement.

Qt, Box2D, and other random musings

2009-07-07T18:01:00.003+01:00

First of all, I'm very jealous of the Linux Desktop gang for holding their summit in the Canary Islands. I did a quick look at the cost and it's not any more than what I spent to go to Stuttgart for Eclipse Summit Europe. I can't wait to hear how it really was.

At that Summit, Nokia announced that they were moving from GTK to Qt for their Meamo Linux distribution for their handheld/tablet type devices. They were upfront about the reasons and it makes perfect sense. The plan is to have Qt as the default toolkit for Symbian devices as well. Learn one API and target them all. This is exactly what I hoped would happen with the Trolltech acquisition. So kudos to Nokia for a smart move.

And I hope through the Intel partnership with Nokia this will spread to Moblin too. For app developers, I think it's really critical that we see some consolidation on the number of mobile Linux platforms. The nightmare I see supporting all the different Linux distros in my day job doesn't need to be reproduced for mobile.

Anyway, that got me thinking again about Qt for my hobby activities. I want to learn what it takes to make games for mobile handsets and what kind of things the CDT would need to better support that. Having your work run on both mobile and in a simulation mode on the desktop makes a lot of sense, and one of the main drivers I see behind Windows adoption of the CDT. Qt would be a great framework for this for a few reasons. First you can target Windows and Linux desktop for simulation environments and the growing number of mobile platforms adopting Qt. And for me, Qt's QGLWidget and Android's GLSurfaceView work almost identically, further supporting my cross platform efforts. I'll have to peak at the iPhone SDK and see if that holds true there too.

Speaking of gaming on mobile. Most of the games I see there are actually 2D games. There are probably a few reasons for that, but 2D games are just easier to do. There's less pressure to actually simulate reality as you get with 3D. To help with 2D game development, a couple of guys in the Android community have ported the C++ Box2D physics engine to Androids NDK (Native Development Kit). Looking at all the cool 2D things I see on the iPhone and given the BSD nature of Box2D's license, I can imagine its driving a lot of them. And the results are pretty cool, especially if you hook up the accelerometer on these platforms. I'll have to play with it and see how easy it is to use.

MinGW on Linux on Windows 7???

2009-07-03T19:54:00.002+01:00

My Windows/Linux world has gotten a whole lot more complicated in the last few days, but I'm really liking how it's set up now.

As I mentioned in my blog entry on multi-target Makefiles, I am using Fedora 11's mingw cross compiler along with gcc's multilib support and am building the little C++ project I'm working on at work for both 32 and 64-bit Linux as well as Windows all in the same Makefile and all on every build of my CDT project. That is extremely handy and I've already fixed a problem early where there is a mismatch between the linux and mingw environments, no strndup on mingw, and was able to do so without switching machines.

This is awesome and I'll be able to produce executables for all three of these platforms for testing all in one shot. Kudos to the Fedora folk for providing first class support for mingw cross compilation and not ignoring the fact that us developers still need to target Windows once in a while. That makes Fedora my favorite development environment by far.

But, alas, Linux drivers suck for laptops. I have a Dell and a port replicator at work and at home. I have a 24" monitor at work running at 1900 wide and a 22" monitor at home at 1680 wide. I swap between the two every day, and often work undocked at home with no external monitor. I could never get Linux to recognize when I dock and to figure out which monitor was hooked up. That drove me nuts.

A couple of things have also happened recently. I've been testing the Windows 7 RC on a separate partition and have started to really like it. As a lot of people have mentioned already, it's what Vista should have been. It doesn't quite have the flash of the Mac, but I find it's a great balance between flash and the stability of XP.

The other thing that happened was that VirtualBox 3.0 has been released and it now has OpenGL support for both Windows and Linux guests. That was one of the reasons I moved to Linux, to experiment with OpenGL there. Now I can do that in a guest OS.

So putting all that together, I've replaces OSes yet again (been doing that regularly for years it seems). I'm now running on 64-bit Windows 7 with two major VMs, one for my fabulous Fedora dev environment, and one for the corporate XP environment I used to have there for Outlook and Netmeeting. So far so good. I get the odd glitch once in a while but nothing I can't recover from and it is a release candidate. But now I have the best of all worlds. Except maybe MacOSX, and an iPhone dev environment. So close...