CDT in the New World

An interesting thing happened the other day which I think shakes some of the foundation I’ve had in my mind about the CDT. My vision was always for CDT to support C, C++, and related languages on every platform. And that has always included Windows. Mind you, we’ve never really done a great job there but we do have lots of users using it with Cygwin or MinGW and you can argue how well they support Windows application development.

The big news was Microsoft’s Visual Studio Community Edition which is a free version of their complete IDE for individuals and small teams. This is different from their Express editions which were severely limited in the end, including lack of 64-bit support, and the inability to install plug-ins into the IDE. No, the community edition is the full thing and is a pretty important step for Microsoft as they try to keep developer interest in their platform.

As long as Microsoft charged money for Visual Studio, I always thought CDT had a play. I’ve done a little work on supporting integration with their Windows SDK (which includes a 64-bit compiler) at least for build. Debug was always a big hurdle since you’d need to write a complete debugger integration that is very different from gdb. So, really, this integration barely worked. And now that VS is essentially free to the market we serve, there’s little point at continuing that effort. The same is essentially true with Objective-C support with Xcode on Mac, which even they are drifting away from to focus on their new language Swift.

But you know, despite giving up on a dream, I think CDT has an important role to play in it’s field of strength, i.e. support for the GNU toolchain, especially as used for embedded development with it’s new found focus as a pillar in the Internet of Things. As I’ve talked about on Twitter and on CDT forums, I am working on a CDT integration to support building C++ apps for Arduino. Once that’s done, I’ll shift focus to a more complicated environment around Raspberry Pi which I hope to add better remote debug support to CDT. Yes, I know everyone loves to talk about using scripting languages on the Pi, but I want to expose these hobbyists to the real world of embedded which is almost exclusively C and C++, and get them started using CDT.

I still haven’t given up on the desktop, at least desktop support with Qt. I really want to make CDT a first class alternative for Qt development. We have a good start on it and will continue with things like a project file editor, easier setup of builds, and import of projects from Qt Creator. The great thing about Qt is that it also is truly cross platform, allowing you to write your app to run on the desktop and then migrate it to your embedded device, such as the Raspberry Pi. And supporting both of these with the same project is one thing CDT is pretty good at, or at least will be once we fix up the UX a bit.

In the past, much like the rest of the Eclipse IDE, I think we on the CDT have focused a lot on being a good platform, almost too much. While vendors have done a great job at bringing the CDT to their customers writing for their platform, including my employer :), aside from the Linux community, few of us work on supporting the direct user of the Eclipse C/C++ IDE. I think focusing on CDT’s areas of strength and targeting specific open environments and not chasing dreams will help me contribute to the CDT in ways that will actually help the most people. And that’s most satisfying anyway.

I have a dream, an Eclipse UI dream.

Humour a madman for a second :).

A few months ago, I was pretty excited about the prospect of Eclipse running against a modern UI framework such as JavaFX. Modern applications have a flow or liveliness to them. They aren’t just a bunch of toolbar buttons and menus that take umpteen clicks to do the things you want to do. They move with animations and effects that make your app feel alive. Not everyone agrees that’s what an IDE needs, but I’d like someday to take the time and experiment to see if it does.

And I’ve seen some of what’s possible. Cole Markham’s talk at EclipseCon this year on using the JavaFX e4 renderers for the RCP apps he was building showed the potential. His apps are beautiful and much thanks to the CSS capabilities and animations in JavaFX. It can be done and it can be good.

But what of the Eclipse IDE? Originally I thought we could port SWT to JavaFX and then introduce JavaFX slowly into the vast collection of IDE plug-ins. From Tom Schindl’s great work on this and his experience with it, I’m not sure either of us, or anyone for that matter, thinks it’ll really work. The paradigms are just too different. Maybe JavaFX can evolve to make it closer (and it is indeed still a young API), maybe not.

Where to then? I sometimes go down a dark path looking to too see where the next revolution in IDEs would come from. Eclipse was quite disruptive back in 2000 and had great success. But have we reached a stagnation point forced on by the architecture and tragedy of commons it has brought onto us (without standards and with uber flexibility, every plug-in has been free to implement their own UX and many have)? Will IDEA lead the way with it’s better funding? Will QtCreator take over the C++ world? Or is everyone just happy with their text editors and command line tools that we’ll regress back to the 1990’s?

Well, if there is to be a revolution, a new IDE framework that will fix all that’s broken with the existing ones, I’d actually like to look back at Eclipse. Often when I explain why we have Core and UI plug-ins for all our projects, I’ll bring up that maybe one day we’d like to replace the UI with something else, something not SWT. And maybe this is it. Reuse the valuable Core plug-ins we have that support build and debugging and static code analysis and source control integrations, and replace all their UI plug-ins with new ones that use a new UI framework based on JavaFX.

Am I insane or naive to think that would work. Maybe I don’t think that would work. But I can dream. And maybe someone with the resources will think it’s a good idea and make that dream come true. Or maybe not.

Motion Sensor to Phone App – an IoT-kinda Project

My son Alex is autistic. That presents a lot of challenges for my wife and I and, of course, for him. He’s generally at peace, but suffers from a lot of anxiety in situations that are new and he really wants everything to work out OK. We also have a very nice backyard with a gazebo on the deck and days like today, my wife and I love to sit out there. But from there we can’t see if someone comes to the front door and we don’t want Alex to have to deal with solicitors or what have you giving him a situation he can’t handle.

So that was the germ of an idea, which of course for me, has grown to a pretty big hobby project (with work implications, of course). Searching for possible solutions, I ran into the Adafruit website which has some great tutorials on how to build gadgets for this very type of problem. They sell a motion sensor for $10 that I could place on the front porch somewhere to detect when someone came up (not everyone rings the door bell and the motion sensor is more interesting).

Now, I want the motion sensor to raise a notification on my phone when someone triggers it. Very cool problem for we architects to have to solve. First do I go Arduino, Raspberry Pi, or BeableBone? Given the simplicity of the hardware, a single sensor, doing a board that has a GPU and HDMI out seems like ridiculous overkill. So I’ve gone Arduino and bought an Uno as well. I love the Arduino because it gets you into the core of the embedded world. There’s no OS, just bare metal and your code, and a few library functions to get you going. Everyone with a computer science degree should have had to do something with an Arduino. It’s the absolute core of what computers are.

Next up, I have this web site, cdtdoug.ca, which I host on DigitalOcean. It has an nginx front end to WordPress for this exact purpose, to host web apps as well. So I want my phone to connect to it, and the motion sensor so I can find out when it gets triggered. Adafruit sells a wifi shield for $40 which is supposed to be good. But to start, I’ll just use the serial port on the Arduino to send messages on my laptop and have a node.js server that forwards it to the server.

On the server, I’m going to use vert.x. I notice a few Internet of Things type projects that are using it. The plan is to have a vert.x vertical to watch for REST calls coming from node.js and eventually from the Arduino itself with the wifi shield. Phone apps will connect to the server using websockets managed by another vertical so that when the sensor triggers, it can send in a REST call which gets forwarded over the vert.x event bus to the websocket server which can the forward it to the phones. It’s beautiful in it’s simplicity and in the minimal amount of code I need to write to actually get this to work.

MotionSensor

So it’s projects like this that feed my passion for the Eclipse IDE. I want to be able to do all of this from a single workspace. CDT to do the Arduino code, Nodeclipse to do the node.js server, m2e and JDT to do the vert.x server, and ADT for the Android app and Thym for Cordova. If I’m missing pieces, I will build them and make them available. A proper Arduino CDT port is first on the list. I’m also curious how easy it is to do vert.x development in Eclipse. And everything needs a good debug solution from end to end (which may be a challenge on the Arduino since it doesn’t have an OS). This would be a great showcase for the Eclipse IDE and it’s place in the Internet of Things. I’m going to do my best to get this working. More in future posts.

P.S. I hesitated to call this an Internet of Things project. Designs like this have existed forever. They were just industrial automation systems with reporting to a central server. But if it gets me noticed, then while in Rome…

Who are you building this for? A UX Story.

We had a great day yesterday at the Eclipse Day Montreal. The program was a perfect reflection of the diversity of Eclipse. Everything from IDE to RCP to IoT and beyond.

David Cummings, my partner in crime here at QNX, and I gave a talk on our work improving the user experience of our Momentics IDE, a lot of which we are now working on contributing to Eclipse. At the end of it we had a great discussion with the audience about how we enact change and make the improvements we need.

During that discussion I had one of those moments I treasure, when the words that explain what I’m thinking finally come and it links everything together. The question arose about how you deal with conflicting requirements. When you have features that people are used to and that advanced users appreciate but are things that overwhelm beginner users and make for a bad experience for them. Who wins?

My thoughts go like this. When you piss off an advanced users, well, they’re pissed off. They make a lot of noise, raise bugs, etc. When a beginner user gets pissed off, he stops using your tool because the barrier to entry is too painful. I chose the beginner. If you can get a new user to see all the greatness that we’re bringing with Eclipse, they get interested in it. They learn how to make plug-ins, and they eventually contribute to fix the things that bug them. The become the next generation of Eclipse committer, and it’s that next generation we desperately need right now.

I’m not saying we do things to deliberately piss off advanced users. We learned that with our work on the Launch toolbar. We make it great for beginners but advanced users found it useless and turned it off. In the latest iteration, we’ve fixed that and made it easy for advanced users to get at the properties pages to make the tweaks they want. It’s a balance, but if you don’t make the best attempt at reaching that balance, it actually harms the community. I wish more community leaders would understand that.

Anyway, I have had a couple of experiences now that confirm this actually works. On the CDT today, we have a fantastic young committer who started using CDT in a previous job and loved it. He was so excited he spent his personal time learning about it and got deep into the code, something that is so awesome about open source. It’s all there. He eventually started contributing patches to the CDT to fix things that bugged him. He did so many that he eventually earned his commit rights and is one of our top committers at getting things done. He was so good, one of our other committers convinced him to go work with them and now he works for an Eclipse IDE group and contributes to Eclipse as his day job.

And he isn’t the first. A number of our committers past and present came that way. I love these people, because they did it because of their passion for making great tools, not because they’re employers told them to. And it’s more committers like that who will help us keep Eclipse alive and well and on top.

So when you’re looking at a user experience problem, think carefully about how you solve it and how you treat the people who raise it. Every one of those people are potential contributors. Make them happy.

CDT goes Dark – as in Theme

With the helpful push from Lars Vogel, and the great color work from Andrea Guarinoni, CDT now has support for the new dark them coming in Eclipse Luna.

I’ve wondered whether dark was good or not and the UX gang that we worked with at BlackBerry were pretty adamant that it was not a good thing. I’ve also read research that said that dark themes were OK, but not for people with strong astigmatism, such as I. For example, I can never use VGA monitors again since they’re totally blurry to me.

When I turned on the Eclipse dark theme for the first time today, it was everything I feared. But after a while, my eyes adjusted to the scheme and wasn’t bad. I think you have to be really careful how bring or dark you make the text, and some of the editors right now have a little to dark a grey for the text for me to focus on. But In general, I like it a lot. In fact, I switched to my current Momentics environment and felt blinded by all the white. “Once you go dark, it’s hard to go back.” (me on Twitter shortly after that).

There’s still other plug-ins that need to do the same change we’ve done for CDT. JDT, in particular which has a lot of black on black text making it unusable. But once it’s all together, I can’t wait to set it and leave it. And I can’t wait to try it with Momentics. I think embedded developers would love a dark theme. Most of the command line gang I see at QNX are all using dark theme terminal windows. Not that it’s a driver at all, but it might help the IDE feel more natural for them.

For now, here’s a peak at the CDT going dark :).

Screen Shot 2014-05-06 at 3.18.54 PM

Tutorial – A Simple Approach to Writing JavaFX Eclipse RCP Apps

I love the architecture of JavaFX. It has a simple and self consistent API that lets you build scene graphs of your UI layout and send it off to the GPU to render. That should give our apps snappier performance and allow for some pretty cool transitions and effects. I can see it replacing both Swing and SWT one day. Hardware accelerated user interfaces are where we need to go to make apps feel alive.

However in it’s current state, it’s tricky to set up your development environment in Eclipse, at least it is today. Tom Schindl does have his e(fx)clipse tooling, but I’ve come up with a simpler way that uses the standard Eclipse Java 8 support. For me, it’s always important to have a development environment that’s easy to set up and understand. Being able to use the base Eclipse tools for building JavaFX RCP apps lowers the barrier of entry for those who want to try out this new world.

This tutorial shows a fairly simply way to build an Eclipse RCP application using JavaFX for it’s user interface. It’s a simple Hello World similar to the standard JavaFX Hello World tutorial. To make it Ecipse-y, I created an extension point that creates JavaFX buttons. In the end, there are two plug-ins. The main one implements the entry point and the second one adds the Hello World button. I also show how to build an Eclipse product for all this so you can use Maven and Tycho to create an distribution you can hand out to people.

Screen Shot 2014-04-21 at 10.06.46 AM

public class EFXApplication extends Application implements IApplication {
    @Override
    public Object start(IApplicationContext context) throws Exception {
        launch();
        return IApplication.EXIT_OK;
    }

    @Override
    public void start(Stage primaryStage) throws Exception {
        primaryStage.setTitle("Hello World!");
        StackPane root = new StackPane();

        IConfigurationElement[] elements
            = Platform.getExtensionRegistry().getConfigurationElementsFor(Activator.PLUGIN_ID, "buttonProvider");
        for (IConfigurationElement element : elements) {
            Object o = element.createExecutableExtension("class");
            if (o instanceof IButtonProvider) {
                Button btn = ((IButtonProvider) o).createButton();
                root.getChildren().add(btn);
            }
        }
		
        primaryStage.setScene(new Scene(root, 300, 250));
        primaryStage.show();
    }
	
    @Override
    public void stop() {
    }

}

I won’t go into all the gory details. You can clone my git repo up on github, http://github.com/dschaefer/tut-efx, to see what I’ve done. But there are a couple of important points I want to highlight and maybe spark discussion on how the approach could be made better.

To start, you need an Eclipse with Java 8 support. I’m focusing on the Oracle Java 8 VM and am leaving the Java 7 JavaFX solution behind. Java 8 is easier to set up, although as you’ll see it’s still not optimal. Get an Eclipse distribution that also has EGit and Maven so you can check the github repo and use the Maven launch (why are maven builds launches?) to build the product.

The biggest hurdle we need to get over is that JavaFX isn’t part of the Java 8 standard. It’s only available in the Oracle VM. So the Java 8 support in Eclipse doesn’t work for JavaFX out of the box, or at least, doesn’t do anything automatically to help you set it up. There are two issues we need to deal with. First, the JDT doesn’t make the javafx package visible. Which I guess is justified because the Equinox run-time doesn’t expose the javafx package either. JavaFX is in the extension class path so unless you enable that, you can’t build against it. Luckily it’s pretty easy to do, although after a while it becomes a bit of a pain.

First step is to make the javafx packages visible to the JDT compiler. Of course, make sure the Execution Environment is set to JavaSE-8 and that it’s linked to the Oracle Java 8 JRE. In the project properties under Java Build Path, click on the Libraries tab and expand the JRE system library. Edit the access rules and add one that makes javafx/** Accessible. That’s it. Now you can access all the goodies in the javafx package in your plug-in. Unfortunately, you have to do that for every plug-in. But it gets us going.

Screen Shot 2014-04-21 at 10.11.21 AM

The next step is to enable the OSGi runtime to load from the extension classpath when it tries to load you javafx classes. This is done at runtime by changing the default parent classpath for bundles using a handy system property. Add this to your launch configuration and any other places you will be launching your app from.

-Dorg.osgi.framework.bundle.parent=ext

Now, I’ve been told this is dangerous because it gives access to all the classes in your extension classpath, even the ones you don’t plan on using and may conflict somewhere, or something like that. But since you’re using JavaFX, you’re tied to the Oracle Java 8 VM for now anyway, so I’m not sure it’s really that dangerous. I’d love to hear more if I’m wrong about that.

The third thing comes at releng time. If you’re using Tycho to build you’re product, then there are a couple of tricks you need to do there. First of those is that you need the latest JDT compiler that supports Java 8. At the time of this writing, Tycho only has a Java 7 JDT bundled with it, but that’s easy enough to fix with a little pom magic for your parent pom.

    <pluginRepositories>
        <pluginRepository>
            <id>cbi-jdt</id>
            <url>https://repo.eclipse.org/content/repositories/eclipse-staging</url>
        </pluginRepository>
    </pluginRepositories>

    <build>
        <plugins>
            <plugin>
                <groupId>org.eclipse.tycho</groupId>
                <artifactId>tycho-compiler-plugin</artifactId>
                <version>${tycho.version}</version>
                <dependencies>
                    <dependency>
                        <groupId>org.eclipse.jdt</groupId>
                        <artifactId>org.eclipse.jdt.core</artifactId>
                        <version>3.10.0.v20140408-1345</version>
                    </dependency>
                </dependencies>
            </plugin>
            ...

The other thing is that you can’t use the SWT-based binary launchers. They somehow set things up so the JavaFX application framework hangs on startup. I haven’t figured out why, but avoiding them works out best anyway. So I’ve written script based launchers and have bundled them as rootfiles in my project. I then set the ws property on all my environments to ‘javafx’. Some day we’ll need binary launchers that support this configuration, but for now, in the .product file, you need to turn off binary launchers. Works like a peach. I’ve even configured the Mac build to use bundling so it produces a MyApp.app folder which runs like a normal Mac app. Just make sure you have the Java 8 JRE set up as your default JRE.

#!/bin/sh
# Mac launcher                                                                    
appRoot=`dirname $0`/../..
launcher=`ls -rt $appRoot/plugins/org.eclipse.equinox.launcher_*.jar | tail -1`
java \
    -Dorg.osgi.framework.bundle.parent=ext \
    -Xdock:icon=$appRoot/Contents/Resources/Eclipse.icns \
    -jar $launcher

And that’s it. No special tools required and you can get started having fun with JavaFX and Eclipse today. In my next tutorial, I’ll show how to take this example and grow it into an Eclipse IDE on JavaFX. LOL, I kid. But that’s the direction I’m heading. JavaFX gives us a great user interface framework to carry the Eclipse IDE into the next generation. We have some very hard problems to solve with backwards compatibility with an SWT port on JavaFX, but you got to start somewhere. Hopefully this little tutorial will get you excited about the possibilities.

EclipseCon 2014 Wrap Up

While I got a few moments here now that I’m home in Ottawa, I thought I’d jot down a few notes from last week’s EclipseCon. For me personally, it was the best ever. The diversity of discussions I had with so many talented people represent the diversity of my interests these days. I’m trying to build a great IDE for my platform’s customers and that goes beyond just the plug-ins we build for them, but to the entire ecosystem. We should be helping with all that because that value helps grow community and in the end our IDE gets better and my customers get happier and I get to work more on Eclipse :).

As soon as I checked into the hotel, I went up to the second floor where I was staying and looked out over the balcony by the elevator and a rush of memories flowed over me. I was at EclipseCon 2005 (mind you I’ve been to all 11 of them) which was held in that same hotel. There were ghosts here all week. I’ll never forget my first experience as a mentor for other projects when a number of groups interested in a Fortran IDE on Eclipse were trying to figure out how to work together and combine technologies. That’s where my friendship with the Parallel Tools team started and it was great to see Greg and Beth back again to relive those memories.

I was trying to figure out what the differences were back then to today. So many companies were scrambling to get their faces seen, joining the Eclipse board, starting top level projects, making product announcements. It was really different. The developers were there to get their projects known but they weren’t really the focal point. And I figure that’s it. EclipseCon is now a developers conference. It’s a place where the community gets to meet, and have a few beers together growing relationships, and to learn about what’s going on that might inspire. And I think that’s a perfectly good place to be. Yeah, the numbers are down a bit again, but I think the developers I talked to got way more out of it than we did back in 2005.

I have to admit that I started looking at JavaFX because it’s a shiny ball. I always seem to be chasing those. But there is a lot of interest in it’s capabilities in the Eclipse context. The CDT multi-core visualizer, for example, is a pretty complex visualization of the state of the dozens, if not hundreds, of cores in the chips these days. It’s all hand rolled SWT paint code with it’s own custom framework for drawing nodes and connectors. I have a feeling there are a lot of such visualizations that we could have in the IDE for representing data of all sorts. I think JavaFX can help there, but that needs to be validated. And if it does, that means we need the best architecture for the Eclipse IDE and JavaFX to make it work. I’ll blog more about that in the upcoming days. Talking with Tom Schindl and Steve Northover (who I’m so glad was there), I think we have some ideas. And, of course, it will require community support to pull it off and that’s the next challenge. To make sure we’re communicating the value.

I had a good chat with Gorkem Ercan from the Red Hat JBoss team. I got to know him when he was doing the Mobile Tools for Java back at Nokia. He’s now working on Apache Cordova tooling, which is good for us at QNX/BlackBerry since we support Cordova as one of our runtimes. I got to learn more about the type inferencing problem in JavaScript, i.e., how do you get content assist to return something useful. It’s a real hard problem and it was good to hear that they were talking with the Orion gang, who are also working hard at this problem. It was also good to see the VJET talk and they also seem to be working on that problem. Why we have two desktop JavaScript tooling projects in VJET and JSDT, I still don’t have an answer to, but it’s good to see that there are others out there who care about having good JavaScript tooling on the desktop.

And last but not least (for now), I had a few conversations with Lars Vogel over the week. He has done so much for the Eclipse community, it’s hard to measure and thank him enough. Everyone knows about his great tutorials on Eclipse development. We’ve all used them, or at least ran across them in Google searches. But what has me inspired is his drive to contribute to the Platform UI project and to solve all those problems we seem to always be complaining about. Why are we complaining and not putting that energy into contributing to make the Platform better. We all depend on it and have such a vested interest. We can’t and shouldn’t depend on others to do that for us. If Lars can drive through and work with the platform team and make change, well, I can to. And that’s what I intend to do. And thanks Lars for giving me that inspiration and I hope others catch it too.

Well, I’ll blog more as I dig into all these different areas. And I haven’t even mentioned the CDT summit we had on Monday and Tuesday. Great things coming there too. For now some sleep and some much needed family time. Then it’s back to work. EclipseCon has fuelled my passion and has given me hope that we can make the great Eclipse IDE even greater.

Coming soon to an upstream near you

Just to tease :)

Screen Shot 2014-03-14 at 10.08.11 AM

I use the new upcoming Momentics IDE for my everyday work with all Eclipse projects I’m working on. Our new updated toolbar supports it all. Pick your launch mode, launch configuration, and target you want to run on, click Build, Launch, Stop. Boom!

Nothing like a little dog food to make a user experience you love to use. We’re still tweaking this as we run into workflows that we hate.

And, yes, we intend to contribute this upstream to Eclipse somewhere. I’ll be showing and discussing this at the CDT Summit and to anyone at EclipseCon who wants to see it in action.

The Desktop is Dead, Long Live the Desktop!

OK, I’m getting old. I’m still in my late 40’s but I remember a time that a lot of people younger don’t. I was in university in the late 80’s and our favorite compute platform was the legendary Sun 3 workstations. They were cool. They had a big graphical display with an optical mouse and a pretty fancy keyboard. They had a lot of power, relatively, had a great OS in SunOS, a BSD Unix derivative. It was a great machine to build software with.

OLYMPUS DIGITAL CAMERA

(borrowed from Wikipedia)

Our love for these machines and similar ones from HP went on well into the 90’s when commodity personal computer’s based on Microsoft Windows NT and Intel CPUs finally became as powerful and feature rich as the workstations of old. And we were OK with that. We were getting pretty tired of spending up to $10,000 on each one of these when you can get an equivalent PC for $2000. Yeah, you had to put up with Windows but they got the job done and had way more productivity apps than our workstations did.

Then something really weird and wrong happened. Consumers decided that they wanted these machines for themselves to run their little browsers and word processors on and to play games with. Popularity exploded and these machines became even more powerful. And we software developers benefited from that. The workstation days were a distant memories and we used to laugh at how little power they really had.

But, yeah, it was wrong. These machines were never meant for consumers. They were business machines and had the UX to match. Why was my Mom learning how to use a mouse and navigate through a complex operating system just to browse here crochet patterns on the Web? Well, the inevitable happened. The computer companies were finally handed their lunch as mobile devices and their simpler consumer friendly UX became hugely popular. “Wait, everyone wants tablets and smartphones. The desktop is dead!”

Well, you guys can have it. One thing that hasn’t changed is the demand for good machines to build software with. While the Desktop follows the consumer into simple-land, and rightly so I guess, an opportunity has opened again for the return of the Workstation. I think Apple has caught on. The new Mac Pro is back at the $10,000 price point and offers incredible power and, again, a great Unix-based OS in Mac OS X. I think there’s a need for similar machines built for Linux although Linux needs a user interface that has evolved at least a little bit from what we had in the late 80’s. But with Wayland and Qt like you see with the Hawaii desktop from the Maui Project, I think that’s getting with in reach.

“But hey Doug, what about software development in the Cloud?” You mean like we did on IBM mainframes and shared Unix minicomputers until the early 90’s? Well, as I fight with the slowness and scalability issues with defect tracking and code review tools shared with hundreds of other developers, I remember clearly why that wasn’t good enough before. We wanted computers on our desks so we didn’t have to be impacted by what others were doing in these shared environments. And you know, check out the CPU specs on that server you’re using out there, it’s probably less than what you have on your lap reading this. So we can replay history if you want, but I’ll take a pass on this cycle.

So, yeah, the Desktop is dead, and probably shouldn’t have ever happened. But I don’t expect this Workstation I’m using, my MacBook Pro, to be going anywhere.

 

EclipseCon 2014: Getting Qt with Eclipse CDT and JSDT

Two weeks to go. Time to get really jacked for EclipseCon 2014. I’ll be giving a talk this year on the work I’ve pretty much dedicated the last two years of my life to, properly supporting Qt development with Eclipse. It’s long been stated that Eclipse, CDT in particular, doesn’t do Qt. Well, it certainly didn’t do it well, but we working hard at changing that. Qt is the foundation for out native Cascades App UI story with BlackBerry 10 and we’re pretty happy with how that’s gone. Now it’s time to contribute back to the community to make sure Eclipse does do Qt and does it well.

This talk will go through the aspects of Qt that makes it difficult for any IDE to support it. It extends C++ in interesting and powerful ways that really makes programming in C++ a safer experience. But, the IDE needs to support those extensions and we’ve done a lot of work with CDT’s parsers, indexer, and editor features to make it so.

An important aspect of the new Qt 5 is the declarative QML UI description language. It’s actually a mix of declarative and imperative using JavaScript to add behavior for events. An obvious choice would be to leverage Eclipse’s JSDT (JavaScript Development Tooling) to support that and we’ve done so. There’s some changes we need to push upstream to make JSDT support non-browser JavaScript platforms. Along with that, we’ve hooked up JSDT’s debugger to Qt’s QML remote debug protocol, giving a pretty nice debugging experience with QML. And there are a few changes we needed to do to make that happen.

If you have an interest in Qt and how the Eclipse IDE will be updated to support it as a first class citizen, come to EclipseCon 2014 in San Franciso and see me Thursday, March 20 at 1:30 in Grand Peninsula F. Love to see you there and get your feedback.