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.

… and with our coding dead… (with apologies to Shakespeare).

Again, I haven’t been keeping this up.. why? Spam is driving me crazy. I’m currently upgrading the server and will put in a captcha to re-implement comments. After all, what’s a blog without feedback?

Adobe Flex/Flash

On the development side, I haven’t been dormant: I’ve been investigating the new Flash and Flex technologies from Adobe.

Since Adobe took over Flash from Macromedia, there has been an all out push to turn the Flash technology into a bona-fide development environment. That makes it a candidate for investigation (especially to one who professes to be a graphics developer.)

The outcome? You can see one outcome on Facebook (this is also an exercise in exploring the ’social media’ platform): Active Biorhythm. It’s pretty cute – if you’re a Facebook user, you should be able to fire it right up (you might need to log in, first.) The first tab shows your six most compatible friends for varying attributes with a series of (active, of course) venn diagrams. The second tab shows your personal values with (active, again) bar-charts. (The ‘in-tip’ value labels is a nice touch…)

The third tab is the most interesting in terms of potential applications, IMHO: Think ‘Google Analytics’ type charting, with active information popups at appropriate places. As you hover over a curve, for instance, the other curves fade into the background and data at that point is reflected in an ‘info balloon’, which has a connector to the table readout value below, for good measure.

The current date can be changed by grabbing the red cursor and dragging it, or by hovering over the pointers on the sides of the graph. A friend can be loaded, either from the compatibility panel or from the name panel on top, and the chart will show comparison values, as well as a drop-down ‘compatibility panel’ for all attributes.

It’s an interesting demo of how to show a lot of information on a graph, without cluttering it up with legends, etc. I’m sure a graphics designer (which I don’t profess to be) could think of some very interesting possibilities. It needs a bit of work, still, but it’s quite functional.

The next exploration in this (Flash/Flex) technology will be a 3d library which has been built on top of Flash, talking directly to the GPU . From what I’ve seen, it looks very promising.

Aside: ActionScript3 is ok – it’s an ECMA-derived script, so there are a lot of familiarities. The only thing I don’t like is the kind of backward typing statements (typing, in and of itself is good, of course).

For instance, to declare a variable of type ‘String’ looks like thus:


var myVar:String;

Nothing wrong with that, but say this is local to a function and you want to promote it to class scope. What you need to do is remove the ‘var’ and the ‘:String’ so the lvalue in the assignment doesn’t have the type/instance declarations – that’s a two select-and-click process (other languages the type/instance declarations precede the variable name – one select-and-click to remove.)

No biggee, just a little bit of a nuisance.

Working with the FlexBuilder development environment is much better than working in the Flash Authoring Tool. The latter doesn’t help you very much — FlexBuilder is Eclipse, so it helps a lot (although not as much as it does with Java.) The only issue is that it produces large .SWF files, compared to those created with the FAT.

So, onward. I’ll be working the rest of the day putting in a ‘captcha’ and updating the wp software so comments can be left.

You will be free to add illuminating remarks when that’s done.

… but no spam!!…

I haven’t written in this for quite a while.  With all the spam I’ve been getting on this, it’s been discouraging to do much more writing.  I’ve currently disabled feedback – will re-enable when I get the chance.

At any rate, I’ve been up to my ears in alligators, learning new technologies (same old story), reinforcing what I know in old technologies (same old story, but new twists), and meeting deadlines.

So, I haven’t had much time to ruminate.

Where I’ve Been

Java, for one – and JOGL: This falls under the category of ’same old story, new twists’, leveraging my architecting application design experience into the land of Java, and the OpenGL/3DGraphics expertise into JOGL (Java OpenGL).

It’s worked out very nicely – Java is, of course, another ‘C’ language derivative with a bit of an emphasis on threading, especially for the UI aspects. The Eclipse developer framework is a joy to use, and I’m happy to see it becoming increasingly available for a number of languages and platforms.

JOGL is a reasonable performer, although with large models, we could see it bogging down. It would have been an interesting exercise to have loaded the same models (protein molecules, in this case) in a C++ based system to benchmark performance on some of the larger molecules. It would also have been a worthwhile exercise to isolate the graphics and try one of the newer scenegraph-based technologies (Xith, OpenSceneGraph, etc.) to try to move to higher level constructs, rather than raw OpenGL. Unfortunately, the funding ran out before any of that could be undertaken.

But, the re-architecting and bugfixing were very successful. Here’s one place the results can be seen (Java WebStart App – I’ve been seeing stalled downloads from overseas, unfortunately. Hit ESC to exit):pdb.org Kiosk Viewer

Where I’m at, Now

Flash and ActionScript have always been on the periphery. I’ve decided to take out some time and investigate these technologies, more thoroughly, with a couple of FaceBook apps as the projected end-result. A couple of observations:

• AS3 is essentially an ECMA-based language. As such, it shares a lot with JavaScript.
• Flex looks like a much better authoring environment than the Flash Authoring Tool – I’ve found the latter to be full of inconsistencies and not “helpful”. Flex looks much more amenable to building applications, which is where I’m focused. And, it’s Eclipse-based.

Why Flash vs. JavaScript or, for that matter, Java?

Easy, in my mind – Flash has a much richer innate graphics set than Java, with a lot of support for animations, curved rectangles, really nice thick line support with endcap definitions, etc. With all that, it’s pretty much guaranteed to be on every platform. There are always performance issues in an interpreted environment – even a byte-code interpreted environment, but Adobe has put a lot of effort into updating the runtime and making it more efficient, and making Flash a more formal and rigorous development platform.

Too bad it doesn’t work on the iPod…