The Symbian development platform (on which I’m currently working) has historically been incredibly arcane. A modified C++ with a non-standard exception mechanism, for starters. And a whole bunch of pieces to install, one of which is a doctored up Eclipse IDE.

Qt doesn’t alleviate the proliferation of installation pieces, at the moment, primarily because everything is still in transition. In fact, you have to install a whole bunch more new pieces to get the development environment together on your desktop machine and on the phone.

QtCreator

One of those available new pieces is QtCreator, Qt’s answer to the IDE.

I’ve used a lot of IDE’s over my career, and they all have their pluses and minuses. MSDEV is great for MS-only applications (and is particularly brilliant in C#). XCode is cool on the Mac, and Eclipse is great for Java. I’ve been a fan of Eclipse since working with it on a Java project a couple of years ago, and so was looking forward to using it in the Symbian environment – since Carbide C++ (the blessed Symbian IDE) is based on it.

That proved to be somewhat less than productive – the environment is insanely fragile. I managed to break the debug perspective completely, just trying to move a few windows around (the Variables window, specifically). It took some research and digging down into the nest of hidden project files to find the proper configuration file to delete and get some order back to the IDE. Then, too, communicating with the phone required yet another panel with arcane settings, and that had to be reset, frequently.

Since I’m using Qt, I thought it would be an interesting exercise to use Qt’s blessed IDE, even thought it’s still at an early stage of development.

Order of Magnitude

I can honestly say, QtCreator has been a lifesaver for this project. For starters, though still in early incarnation, it’s really good and intuitive to use for Qt development. And, it seems to communicate with the phone more readily.

There are a lot of glitches, still – I have yet to get the on-device debugger to work. Judicious use of qDebug() statements have been the stop-gap measure around that – effectively reducing debugging to the proverbial ‘print statement’ technique. Not optimal, but it works. And I can’t get the debugger to work on the device in Carbide-C++, either, so it’s no effective difference, there.

Better than nothing.

But, what has been the real lifesaver has been the ability to take advantage of an outfall of what Qt ultimately is: a cross-platform development environment. What this means in practical terms is this: you can do a lot of development on the desktop!

When you install Qt, you can install two versions – one for the desktop, and one for the phone. QtCreator has a (admittedly wanky, but slated for improvement) configuration panel that allows you to switch between build configurations: desktop or device (actually, there are two configurations for the device, as well – emulator vs. actual device.) You have to flip a bunch of switches to do it, but I’ve gotten it down to a fairly manageable routine and can flip between the two environments with relative ease.

That ability has been nothing but a godsend (or maybe a troll-send) for this project of limited funding and limited timeframe. Turnaround (the time it takes to go through a code, run, debug, fix and do it again cycle) on the device is slow. Turnaround in the emulator is even slower. But turnaround on the desktop is fast – no loading required.

Because of that, I’ve been able to do a large bulk of the coding effort – getting the big stuff in place – on the desktop. It helps to create an appropriately sized main window, and you do have to have a jumparound here and there (primarily for the OpenGLES stuff and the menu system), but most of the code and components are exactly the same.

So, when it comes time to deploy to the device, most of the hard stuff has been done. Now you can focus on the harder, device-specific stuff.

Not the Same

Just to come full circle, QtCreator has some real promise. It has glitches – the VIM emulator is a great idea, but I’m seeing a bunch of issues with it. I’m told that much of this is fixed in the newer version.

It’s difficult to specify and organize source folders – I’ve taken to creating source file ‘hulls’ on the command-line in the directories I want them, and then update the .pro file, accordingly. The IDE will honor what you’ve created, and show appropriate folder organization.

Not on the Mac, though – the project contents are just a flat list of entries. You can still get to stuff, but you may have to scroll through a long list of other stuff to get to it. I imagine that will get fixed in the next update or two as well.

Summary

Overall, I think this will only get better. The Trolls (now part of Nokia) are working on this furiously (note the announcement of Meego and the parallel announcement that Qt will be the development platform of choice on that environment – it already is on Maemo).

For me, QtCreator will definitely become the development platform of choice for future Qt applications, with decreasing reliance on the platform-specific IDE.

Yet a new platform to exercise my Qt chops on.

As you may or may not know, Qt has been acquired by Nokia. It appears that Qt will be the development environment of choice for all of Nokia current and future OS’s, including Symbian, Maemo, and the newly announced Meego.

And that’s a good thing.

Leveraging Qt

I can speak for a newbie getting into the Symbian S60 environment: If it weren’t for Qt, this would have been a much more difficult endeavor.

As it was, I was able to put together a pretty sophisticated molecular modeling app, complete with 3D OpenGLES visualization, in about six weeks, thus far. (Still putting in HTML downloads and cleaning up interaction.)

It’s not without issues. The Trolls and Nokia are still getting to grok one another. So some things (like the menu system) display some strange behavior, and Qt doesn’t support OpenGLES on Symbian, yet (at least not on the S60 devices.) So, I’ve had to ‘go native’ for the OpenGL. Not the end of the world – it just means opening up a Native Symbian window and creating a QObject-based class to serve as a controller. It’s working fine.

Trying to do this in native Symbian would have likely at least doubled the development time, I think. By leveraging the Qt knowledge already gained, the process of moving to a new platform like Symbian is greatly facilitated.

Now, if we could just get Qt on the iPhone and Android (efforts are underway for these – see here and here.)