Monthly Archives: April 2009

Writing Eclipse Plug-ins in C++

Well, not the entire plug-in. But I thought that would get your attention.

After spending a while mulling around with embedded Linux and Qt and qemu and thinking about OpenGL ES and how I’d build a handheld console or set top box that had a 3D graphical environment using something like Clutter, I’m now trying to figure out what kind of tools you’d need for such a world where 3D graphics was common place.

That led me back to something I tried a couple of years ago, trying to get OpenGL rendering in Eclipse. The idea was to provide a complete tool suite for building 3D games in Eclipse. We have C/C++ covered with the CDT. You might also want some 3D modeling tools for building characters and scenes. Why couldn’t that be in the Eclipse environment as well. Yes, these are usually done by different people, but I’m thinking of the small, independent developer shops where that may not be true.

The OpenGL canvas widget in SWT makes this pretty easy. I installed the LWJGL library that allows you to make OpenGL calls in Java and I got the Snippet that draws a torus spinning around in an SWT window running. Very cool.

But as I often mentioned here, I “hate” Java (well, it’s pretty much a love/hate relationship since I still pick it for my day job on Eclipse technologies). I want to have the option of using native CPU capabilities like SIMD instructions you get with the SSE family instructions. So I’d prefer to do as much as possible in C++.

So I did that. I got rid of the LWJGL code and replaced it with my own native library that implemented an init, resize, and draw routine. Essentially this is all the code needed to render into the canvas and you can do the rest with a few Java calls to set the current context and to swap the buffers. Very very cool. Now to get this running in an Eclipse editor and we’re off to the races.

Here’s a snapshot of what I have so far. And yeah, it looks like the LWJGL version, but, trust me, all the OpenGL code is in C++ behind the three native methods:

Planet Eclipse Ego?

I was trying to point a buddy of mine (who actually should know better, but anyway) to Planet Eclipse. He replied, it takes me here: http://en.wikipedia.org/wiki/Planet_Eclipse_Ego. I laughed long and hard.

So is it true? Is there a Planet Eclipse Ego? I’m probably guilty on that a bit. I find myself yearning to post to see my name up on the Planet, instead of just waiting to write something people would actually care about. But almost all the other posts are very informative and I don’t see much evidence of any sort of “ego”. Not much anyway ;).

BTW, Pat posted a comment on my last blog about being interested to pay a couple of bucks for the CDT if he could get it off an App Store. Maybe that’s the answer on how to get more funding for Eclipse development. And it plays inadvertently into Bjorn’s suggestion to stop doing builds at Eclipse. If you want Eclipse for free, check it out and build it yourself, just like with most other open source packages. If you want someone to do that for you, belly up to the App Store and get yours for cheap. Hmm…

App stores, the new economy?

You can’t help but appreciate what Apple is doing with it’s App Store which recently sold it’s one billionth app the other day. That’s a lot of apps, and that’s a lot of money going from the consumer’s pocketbook to the software developer and Apple. Apparently the Apple App Store now has around 35,000 apps listed. A lot of them are free and almost all of them are available for under $10. Certainly accessible to the masses.

Being a software developer, I can’t help but envy the guys who are writing these apps. You hear the stories of guys who worked weekends in their basement to make good but simple apps that rake in revenue in the 6 digits in a matter of months. I don’t think there are a lot of similar stories, but it does raise the eyebrows.

I’m also not clear how open Apple is with it’s development environment. From what I’ve been told, you have to buy it from them. It’s cheap, only $99 to get started. But their environment only runs on Macs of course and the feedback I’ve been hearing is that their Xcode IDE isn’t anything to write home about. And there is interest in bringing Eclipse and the CDT into the picture.

So the question that comes to my mind is whether this success can be replicated by someone else. And, in particular, I’m looking at all these ARM SOCs with 3D graphics and multimedia decoding hardware running embedded Linux. It looks like this should be a no brainer.

Or is it? These platforms are easy to build but technology doesn’t make an industry. My son has an iPod Touch and it’s a pretty slick device that I’m sure cost Apple more than the $200 we paid for it, or at least they’re breaking even on it. No, to build a successful platform, you need an ecosystem and that ranges from the SDK the developer uses, to easy access to their wares via an app store or such, to slick looking hardware consumers crave.

It’s no easy task, and I see attempts by the open source source community with platforms such as Open Pandora doomed to failure. It’s ugly, clunky, expensive, and lacking that ecosystem to make it successful. I appreciate their attempt. And I think it could work, if you got the big handheld vendors involved to build the hardware, and then used open platforms and tools, such as Linux and Eclipse, to build the apps, and then some one to build and maintain the app store to spread the wealth. But then maybe I’m dreaming or wouldn’t someone have done this by now?

Update: I totally forgot about Android and it’s app store. But then I’m so totally biased against Java right now, I find it hard to imagine you’ll ever see the sleek apps that Apple has. I’m just weird that way. But I would be happy to be proven wrong.

Eclipse is a Drug and other Musings

I haven’t written anything here in the last few days and was starting to get the urge to write something, anything. I feel compelled to say something about Bjorn’s impending departure from the Eclipse Foundation. But I’m not sure I have much to say. As I mentioned in a previous post, he wears his emotions on his sleeve at times so I wasn’t particularly surprised. But I too have a sense of change at Eclipse having been involved for almost seven years now.

Maybe it’s because I’m very part time on the CDT in my current job and miss working daily in the open. But I look around the CDT project and see the same is true for many of us. And yeah, the CDT has a lot of functionality today already and we’re pretty much in maintenance mode. But there are some cool things we’ve started talking about, like introducing static code analysis capabilities, and the build system is in much need of a redo. I think there’s enough there to generate excitement, I just wish I had more time to promote that. But we’ll see what I can do anyway.

And that’s the theme of this post. For most of us working on Eclipse, it is very much like a drug. I’m hooked on it. We see a lot of people leaving companies only to find them pop up at another company that also works on Eclipse. We’ve even seen high profile Eclipse people leave the safety of their mothership to strike out on their own as Eclipse consultants to continue to help feed the Eclipse ecosystem. Once you’ve been there, you understand why. There are so many good people and so many high profile companies involved at Eclipse, it’s certainly a high to be working at it.

So I don’t worry about Bjorn leaving. I know he’s hooked too and won’t go far ;).

BTW, just ran across a blog entry describing how to use the CDT for Linux programming with OpenGL, something I’ve started to focus on in my hobby time. The instructions are a bit out dated, and I should do some real webinar tutorials on how to do things like this. But I’m fixated on the blog because it has a music player embedded into it and is playing some of my favorite metal bands :). Cool blog marketing trick. BTW, blogging is a drug too 😉

Fun with Qemu/Qt

Just for fun (and maybe profit), I thought I’d try and get Qt running on the mini ARM Linux setup that I used for my tutorial at EclipseCon. Low and behold, all I had to do was build it with the compiler I got from CodeSourcery for ARM and it worked!

Now there isn’t a whole lot of magic here. It’s using the Linux framebuffer device that draws to the screen. I’m not sure how it would look on a real device but it looked might fine on qemu. Here’s a snapshot of it running on my laptop, which is now solidly Fedora. It’s running the browser demo app and has loaded my blog just before I posted this. It took a little while to load and render, but again, it looked pretty good.

Having gotten this far, I start to wonder how much better it would be if I had OpenGL ES emulation in qemu. Would it be faster? Curiosity might kill this cat…

WolfenQt: Proof in pudding

An update to my previous post. As proof I got it working, here’s my blog from earlier today. You can’t see the flash since apparently the adobe flash player bypasses the widget set and opens a native window directly. Wonder where it showed up… At any rate, lots of fun. And with OpenGL mode turned on, performs quite nicely and the widgets are quite readable. Click on the picture to see full size. Very nice.

Widgets in 3D: WolfenQt

As the shiny balls spin around in my world, Qt has jumped back into the foreground. My Fedora laptop is busy building 4.5 as I write this and slowly catching on fire (man these things get hot when they’re busy working). While that was going on, I took another look at how you’d implement Qt widgets in 3D space, kind of like Clutter does in a GTK fashion (mind you I think those are just static 2D images, not widgets).

Low and behold, I came across the Qt Lab Blog entry by someone there who actually has a demo of Qt widgets running in a maze similar to the old id games. He called it WolfenQt. Take a look here:

Very cool! This is exactly how I was hoping it would look and feel. And Qt has the framework to make it happen. I need to do some experimentation with it once I my 4.5 compiled to see how much of this is done in OpenGL versus software rendering. Looking at the code it looks like quite a mix of both. But from the video, it looks fast enough. And I do know the marching guy is rendered using OpenGL at least.

This is the kind of innovation I’d love to see. We talk a lot in the Eclipse world about Java thick clients and Browser/Server architectures. But there’s still so much more you can do using native APIs that take advantage of all the new hardware acceleration capabilities that today’s platform providers are giving us.

And the CDT is such a natural IDE for this new world. With all these new platforms, developers really need a cross platform cross target development environment to work with them all. The goal for my CDT work right now is to show that off and put together IDE packages, like Wascana and maybe something with DSDP for embedded, that can be used in these environments.

On the future of Eclipse

Another great post by Bjorn on life at Eclipse in the new world and a great follow up by Michael Scharf on his thoughts on major changes needed to get there. These two posts made me think about what I’d like to see as a way to take Eclipse forward into the future.

Bjorn draws up a nice, clean looking “architecture” on how the cycle of value feeds the Eclipse ecosystem. Committer -> Project -> Product -> Profit -> Committer… Unfortunately there’s a week point in this cycle which I fear will blow the whole thing up, and that’s the assumption that vendors making profit on Eclipse-based products will be compelled to fund Committers working on open source projects feeding those products. I’ve seen too many vendors in this position not do that.

It’s frustrating to see so many products based on the CDT and less than half of them contribute back to improve the CDT. Maybe the existing committers have done so good a job that they don’t have to. Or maybe they’re not big enough to devote developers to the cause in a significant fashion to justify the cost. What ever the case, we all know how hard it to bring in new contributors. You need to “Create the Need” for them to come. It certainly isn’t out of good will, especially in these times.

Assuming the cycle fails all together, how do we ensure Eclipse projects remain healthy with new contributions? Michael brings up a solution that I’ve wanted to see for a while. He brings it up from an architectural perspective, which is what he does :), but I bring it up from a political perspective. The members should fund a team of core developers to ensure critical Eclipse projects continue to grow. These developers would be vendor neutral other than to follow the wishes of the members. The Foundation can help co-ordinate this but it’s really on the Eclipse membership to make it happen.

The best example of this I know is with the Linux Foundation where they state that one of their goals is “Protecting and Supporting Linux Development”. Now Linus doesn’t work for the Foundation, but the members do fund his work there to ensure he can continue to work full-time and independently on the kernel. I’m not sure how well this is working in practice, especially with people other than Linus. But it’s worthy of a look.

Interestingly enough, a lot of the members of the Linux Foundation are also members of the Eclipse Foundation. But, would such a policy work at Eclipse?

The Rise of the User Community

I’m a big Bjorn fan. I’ve gotten to know him pretty well in my years of involvement with Eclipse. There is no mistaking his passion for open source communities and he’s like me, he wears his emotions on his sleeve when things aren’t going as well as they could. I’m really enjoying his series on the State of Eclipse. Most of his points I totally agree with based on my experience with CDT, e.g., the need for Diversity and the continuing battle between the User and Vendor communities over the need of an Eclipse product that users can count on, where as I stated in the comments, this is an area that is fundamentally broken at Eclipse.

However, I can’t agree that his solution of relying on the members to provide free distributions of Eclipse to replace the distros available at eclipse.org, is the right solution. I’ll go further and say it won’t even work. As I also stated in the comments, the members that produce commercial IDEs do so in competition with the free distros from Eclipse.org. Making a free distro available from their web sites and supported by them makes no business sense, and knowing sales people as I do, they’ll veto it immediately to protect their revenue. Some companies may differ and that’s the only hope I see for it.

And there’s another reason why the distros at eclipse.org are important. There is a growing list of large User companies that are beginning to contribute to Eclipse to support the free distribution with their user base. You’ll notice that the CDT has committers from Google and Ericsson, both of which are examples of this. Without their contributions, the CDT would certainly be worse off. I also met with another such large vendor at EclipseCon who also promised as their developers get up to speed they’ll be contributing.

For the CDT, this is the most promising area of growth in the contributor community, and these guys rely on the distros from Eclipse.org. I’m not about to shoot myself in the foot and even if the Foundation put a stop to this (which Mike assures us won’t happen), I’d still make a C/C++ IDE available from the CDT store.

It’s been a great debate and that’s what’s so great about open source communities. Everyone has the freedom to state their opinion, Bjorn included. Take advantage of that and think about what they are saying. You might find yourself changing your mind. But don’t do it in this case ;).

Putting on my Fedora

Well, I did it, I finally did it. I ordered a 320GB drive and set up a dual boot situation with my old Windows install and my spanking brand new Fedora 10 on the rest of the disk. So far so good. It wasn’t a perfect process, including a 4 hour shrink of my NTFS partition. But I’m up and running. And I have an out to go back if things go bad, but I have a feeling I won’t.

I have a Dell D830 and had to install the Broadcom wireless driver and the nVidia driver for my NVS 140M graphics chip. Now, since these aren’t under open source licenses, you have to get them from other sources, in my case rpmfusion.org. This is part of what sets Fedora apart from Ubuntu. With Ubuntu, it’s a lot easier to set this up. You know you can mix GPL and !GPL and it’s OK ;). At any rate, I deal with it since I feel Fedora is a bit crisper, especially for those of us who think they know what they’re doing.

So why would I bother doing this? With Eclipse, Windows is a pretty fine development environment. The command line environments there are abysmal, but that’s why we work hard on ensuring that you can do all your work from inside Eclipse. But that’s probably it. I want to get back into an environment where command line is king (I used HP and Sun workstations long before becoming a Windows developer) and get a better feeling for what development life is like there. That and as I’ve mentioned before here, Linux is just the best environment for building embedded Linux platforms which is my hobby as of late.

Anyway, we’ll see how long I last here before running back to Windows. As I have it, it’s not too far away just in case, just over there on /dev/sda1 and in a VM coming soon.