I’m getting ready to open-source QXSAP (a Qt-based multi-lingual and simple marshaling parser) and, of course, before doing that, I need to get it into a source control repository, of some sort.

In the past, that’s been SCCS (Source Code Control System), RCS (Revision Control System), CVS (Concurrent Versioning System) and finally SVN (Subversion), with a couple of side trips to some strange source control systems, whose names I forget and would rather not recall.

Something New: Git

Now, the latest thing is Git, created by no less a luminary than Linus Torvald, himself. I’m not sure if the name is an acronym that stands for something, or if it’s just a play on the slang term to ‘git’ something. Whatever – it’s the VCS du jour, and it’s being used by a lot of important (to me) organizations, primarily Nokia for Qt and all it’s sub-components.

Gitorious is the repository of choice for Qt-based objects, so that’s where I want to put QXSAP.

Which means I’ve had to spend the last couple of days getting up to speed on Git. From what I’ve seen, it looks like it’s capable of doing anything it’s predecessors can do. I like the idea of having a local repository, and that the repositories can communicate with each other and update themselves. Beyond the standard required features (fetch/push/branch/tag, etc), the ’stash’ mechanism seems kind of interesting.

Start out with the basics, and then broaden the scope, from there.

Until the next ‘new best thing’ comes along….

It’s occurred to me that, having worked in a number of languages and platforms, lately, just how much an influence Qt has been, particularly the signal-slot mechanism.

That single mechanism is, in my mind, as much an innovative development as the subroutine, the library, and the class.

Why so?

Fundamentally, because it provides a mechanism for incredibly strong isolation of modules, which, in turn, makes them more likely candidates for re-use. It also allows for stronger modular development in general – you can focus tightly on the functionality of the module and – perhaps even more importantl – you can hook tests to the module with ease. Unit testing is an easy and natural fallout of signals and slots.

IT’S WHAT I HAVE coined as ‘connection-based architecture’. (In ‘pattern-speak’, it’s called the observer pattern.)

Whatever you want to call it, it’s the best thing since sliced bread.

Once you’re exposed to it and have to go over to another language or toolkit, you immediately look for an equivalent mechanism in that technology. Some toolkits/languages provide the function inherently, others somewhat. For instance, Objective C implements it as part of the language construct. In fact, you could look at Objective C and wonder if Trolltech didn’t use it as a model – in effect turning C++ into an Objective C implementation. The syntax of Objective C for sending messages is a bit funky, but the functionality permeates every class declared in the language, which is better than Qt can do – you have to derive from QObject or embed a QObject-based instance to use it in C++.

The .NET CLR languages have a corollary in their delegate mechanism (not to be confused with Qt’s ‘delegate’ base class). Essentially, you can declare a delegate as a singular notification mechanism that behaves very much as a signaler, and you can register classes to receive it’s signals on a function. Syntax variants to declare and use delegates vary from language to language. In VB, it’s terrible (unless changed recently.) In C# (really the only language to write .NET apps in, IMHO), it’s easy.

As you go down the language line, it becomes increasingly difficult to use this kind of mechanism. ECMA-based scripting languages (ActionScript3, JavaScript), for instance, don’t have quite an equivalent mechanism, but the event mechanism is closely analogous. It’s reasonably easy to create a custom event and provide handlers for the event.

Server side languages are harder. Java actually has an Observer class, but it’s kind of clunky to use and not typesafe. Perhaps with the emergence of the generics construct, it may be easier to implement a signal-slot type of mechanism.

Of course, signals and slots are not the only thing that makes Qt a standout technology – the window and widget abstraction are often the rationale for using Qt in the first place. If you’ve ever tried to create a multi-platform application from scratch (I have – pre-Qt), it’s a lot of work and you’re often restricted to lowest-common-denominator functionality.

And, Qt provides some other niceties, as well – the bundled 3rd party functionality for things like XML handling relieves you from having to build and support these things as extras (which can be a difficult endeavor in a multiple-platform effort.)

But, the real conceptual leap (unless you’ve been a NEXT/Mac developer working in Objective C) is the signal-slot mechanism. The rest is UI abstraction, a certain amount of architectural framing (which is useful), and bundling.

That dynamic connection-based isolation capability is what I look for any time I have to make a move.

It should come as no surprise that ActionScript3 (Flex/Flash) are second class citizens in the Facebook app world.

But, that doesn’t make it any less frustrating, when you encounter it.

The most recent turn appears to involve the app installing itself into the users account. This used to work swimmingly well. Now, all of a sudden, I’m discovering my potential users can’t install. They never get the ‘Allow’ dialog and the app just hangs on connection.

Various tests show that all of my Flex/Flash, apps and test platforms do this, so it’s not just the app in question. The PHP tests, of course, work swimmingly well.

Other AS3 app developers have noticed this, too, and have had to implement a range of workarounds to fix it. I think FB has screwed up their permissions files for AS3. It would be nice to get FB’s attention to figure out what went wrong, or Adobe’s, but that’s like trying to get through to MS. All you can do is spatter messages on the boards and pray.

So, I’m in the middle of figuring out how to do the workarounds and still stay in the AS3 codespace. Another alternative is to let PHP set up the session and then the Flex app can just attach itself to that session.

Of course, once I get this many-days-endeavor implemented, FB will fix it, and everything will work properly as it did before, in the original context.

But, should they mess up again, the workaround will be a good failsafe against that.

Grouse, grouse. Ommm, Ommm.

I recently built a third party source on the Mac, only to find it had a number of unresolveds (link errors.)

If you build in XCode, the tool is kind enough to tell you what’s referencing the unresolved(s). From the commandline, it’s not so obvious.

Since this is third party code, I don’t want to have to go through the hassle of building an XCode project — but I need to find out which modules were referencing the link unresolveds.

Finally, after a bit of head-scratching, I got the solution — so I can share it, here, if you’re unlucky enough to be searching for this needed capability:

The Solution – Getting the Module/Filename That References the Unresolved

You need to enable a link flag ‘-y’, followed by the unresolved symbol (you’ll get that from the failed link output.) Go into the Makefile and find LDFLAGS (’ld’ is the gnu linker — this is the typical Makefile variable for the options) and add the ‘-y’ flag, followed by the symbol, like this:

LDFLAGS = -y__2435ZClass5FunctioniiiEi [rest of options]

Some of the symbols can get quite long — make sure you paste and copy the whole thing, including the leading underscores. Next time you do a build, the link step will output a line as to what module in your project references that symbol (yay.)

Your work’s not necessarily over — the lib I was building uses a very complex class hierarchy, and it wasn’t apparent which lines of code were causing the unresolved, even though I knew what file it was happening in. If that’s the case, then what I do is selectively #ifdef out parts of the file until I can make the unresolved symbol appear and disappear in subsequent links. Then I can narrow it down to the offending line and fix it. (You get a whole bunch of other unresolveds as you comment out sections of the code — ignore those, of course.)

Tedious, but it works.

I imagine the same would apply in a linux/bsd environment — anything that’s using the Gnu toolsuite.

rickb

The code and demos for this discussion can be found here: http://www.kis-systems.com/examples/QXListView
There are executable demos for Mac,, Windows, and Linux.

An ‘Active List’

I’ve been working part-time for the past couple of months on a project that has been buzzing in the back of my head for a long time: upgrading a piece of ‘active list’ functionality to Trolltech’s Qt 4.

Basically, the idea is this: We want certain cells in a listview to be ‘active’ – i.e., when you click on them, something happens in the app, immediately. Furthermore, we’d like these cells to look and behave like native widgets (checkboxes, radio buttons, etc.), but, of course, we don’t want to load up the listview with a few thousand widgets to achieve this.

Original Implementation: Qt 3

The original implementation was in Qt 3, and was a real bear to do. I had to intercept a lot of events and signals and do a lot of overrides to QListView — ostensibly not an unreasonable requirement (this is OO programming, after all) — but many of the overrides and signals didn’t behave as expected, or had funny side effects. Ultimately, I had to resort to a few tricks to get “way under the covers” and ferret out internal functionality.

It worked, but many aspects were not an optimal or happy solution. I had to document profusely what I was doing, and flag caveats where I was relying on undocumented internals that could change at any time.

Qt 4 to the Rescue!!

So, along came Qt 4. The trolls had refactored everything in the ListViews’ implementation to align with their new Model/View architecture.

Eventually the project wound down and I was no longer part of it. I did a feasibility paper on moving QXListView to Qt 4, but I wound up moving on to other things and the idea was shelved.

Eventually I found myself in between gigs, Qt 4 was by this time way beyond any stability issues, and this problem had been gnawing at the back of my head for the past couple of years. Time to push it to the top of the stack.

The Port

I’m happy to report that the port to Qt 4 wasn’t particularly onerous (despite some of the horror stories I’ve heard from others.) I did have to pretty much rewrite the entire thing, but I didn’t have to resort to any funky tricks to make it work. I did have to follow some of Qt’s internals to see what it was doing and what it expected, but that’s just part of Qt development — more importantly, I didn’t have to ferret out or use anything undocumented. I did have to derive a whole bunch more classes and figure out their inter-relation to each other. And, of course, I had to fit the paradigm into the Model/View indexing scheme. None of that turned out to be terribly onerous, either.

There was a bonus: editing text fields in the Qt 3 implementation would have required significantly more effort. Likewise, re-ordering the columns would have required more effort, since we would have had to do a “logical” vs. “display” mapping (and keep it all synchronized and current.) As a result, those features never really did make it to the “todo” stack. In the Qt 4 implementation, however, those features basically came along for free.

A Good Result

The outcome is a functionality that I think will still be very useful in future projects. And, if nothing else, it’s a good example of how to override and turn Qt’s Model/View architecture to do your bidding.

And now, of course, I need to put this away and get on to the “next important thing”…

Now that the Mac has finally settled down, I’ve been moving my development efforts off of Windows and onto the Mac.  And just recently, I’ve done a partial upgrade to Leopard (hedging my bets by installing it on an external USB drive.  Best of both worlds – I can boot Leopard off the USB, and Tiger off the internal.)

XCode is a reasonable IDE – better with the Leopard incarnation.  The integration with gdb is tight – I’m having to go to the cl gdb less frequently.  Qt is working just fine on the Mac, with no surprising ‘Mac’ gotchas.  (In fact, I’ve gotten more ‘gotchas’ in the linux environment than I have Mac.)(Or Windows.)

A few things I miss in the Windows environment:

• Visual Studio has better capability to look at out-of-scope expressions.  If I want to examine the contents of a pointer, it’s easier in VS than in Xcode.
• Visual Studio’s ability to debug Javascript in IE is simply awesome – it looks and behaves pretty much like any other language in the IE.
• Windiff is still the best windowed comparison program in the land.

For PHP development, Zend’s Eclipse IDE port works fine on the Mac (and the latest incarnation adds a lot of features.)  For first cut debugging of Javascript, the Firefox debugger handles most cases – although in a crunch, I’m tempted to go back to MSVS for the more puzzling situations.

Still, for the most part, I’ve been ‘living in the environment’ and haven’t been tempted to shift back over to Windows for anything in particular.

So,  the Mac is becoming pretty much my mainstream preferred development environment.  With the addition of Parallels and a few scattered VM’s , I can do the verification builds and debugging on Windows and Linux as necessary, using net shares to access the central development environment.  There’s a bit of a time penalty for going this way – but I don’t build frequently in the VM’s and the trade-off for not having to carry more than one machine more than compensates for a slightly slower build.

Ah.  There is one area where the Mac is really hands-down the preferred platform: imaging.  For one thing, you can color profile both displays – an annoying shortcoming in Windows (XP, anyway).

I’m becoming more of an advocate of namespaces.

Traditionally, they’ve been defined informally by prefixing function and/or variable names with some unique mnemonic – such as ‘Q’ for Qt stuff, ‘wx’ for wxWidgets stuff, or even something as potentially ambiguous as ‘C’ for MFC stuff.

All well and fine and helpful, but you can still run into name collisions. For instance, I was browsing the mac utility headers a while ago and ran into a raft of ‘QT’ names – for QuickTime. Dangerously close to ‘Qt’.

The newer languages, such as C# and Java, enforce namespaces. In C#, you can’t write a single line of code, unless it’s wrapped in a namespace.

The usefulness was heightened for me in a recent project with C#: we were attempting to use an underlying module for statistical binning and drawing. But, we needed a highly optimized version so we could dynamically select bins and draw the results on the fly.

Some customization was in order.

Now, in an ideal world, we would go to the creators, explain what we needed, and collaborate with them to get the enhancements we needed. In the real world, though, the creators are off doing something else highly urgent, and we’re not on their ‘to-do’ list.

So, we did the undesirable: clone the module and get the modifications in, ourselves.

Of course, we didn’t want our version to collide with the older version. How to avoid? Simple: since it’s C#, there’s guaranteed to be a namespace associated with the module. Just change the namespace of our cloned module and proceed.

Voila! (I’m writing this in Paris, so I get to stick in my bit of francaise.)

Of course, things aren’t quite so simple – the binning module used several namespaces (a bit of fragmentation overkill, IMHO), and relied on other underlying modules, which had to be detected and determined if they needed cloning, namespace changes, et al. It still can get pretty ugly. But the namespace feature helped.

Another time when namespaces would have been useful was when a somewhat recalcitrant vendor provided a package with a modified libjpg. Naturally, none of our stuff that relied on libjpg worked any more after we integrated their new code…

After the initial shock and dismay, we had to come up with a solution – the vendor was in Germany and were perfectly happy with the solution, as it was, so were disinclined to make changes. In that case, I think we isolated their libjpg into a fully resolved dynamic library along with their system, and didn’t export the jpeg functions. A pain in the ass, to be sure.

Back then, namespaces weren’t widely supported in the compilers (notably, Microsoft), but had they been, it could have been a better solution. Granted, libjpg is in C, but it can be compiled as C++ and then wrapped in a namespace that would prevent it from colliding with our libjpg (assuming we could get the vendor to cooperate.)

As software grows, and applications become more of a ‘mash-up’ of different modules, namespaces can become an increasingly important construct to eliminate conflicts. For instance, if Trolltech wrapped everything in a ‘TT’ namespace, or, better yet, a ‘TT_QT’ namespace, it would disambiguate them from any other code that might just happen to start with ‘Q’. Like ‘QT’ for QuickTime.

So, in my current effort (creating an extension for Qt), I’m wrapping everything in a namespace (’KIS_QX’). It means users will have to sprinkle ‘using’ statements in their code. A bit onerous, admittedly, but I think utimately that namespace usage is a good habit to get into.