Tag Archives: qt

Qt visual artefacts on Mac OS X 10.6

deploy_nearly_everywhereThe release of Mac OS X 10.6 (Snow Leopard) snuck up on me while I have been working hard on a major new release of PerfectTablePlan plan. I didn’t really want to risk messing up my stable Mac development machine by installing it, so I asked testlab2.com (who have been doing some third party testing for me) to test my latest beta on it.

Bad news. All the combo boxes in my application (which work fine in Mac OS X 10.3, 10.4 and 10.5) have visual artefacts on Mac OS X 10.6. They work fine, but they don’t look right. I wondered if the artefact could be unique to some weird configuration on testlab2’s test machine, so I asked the fine folk on macsb mailing list to see if they could replicate it. 4 of them tried (thanks Cesar, Jon, Aaron and Pierre) and they all saw the visual artefacts. Damn.

I posted a question on the qt-interest forum. The single response (thanks Francesco) mentioned that this issue had been reported in the Qt development blog. I managed to find the blog post, applied the recommended single line code patch to Qt 4.4.2 and rebuilt everything. Cesar from macsb kindly re-tried the new binaries and reports that this improved things, but some artefacts are still visible the first time a combo box is shown. Perhaps the patch works better for Qt 4.5.

Note the artefacts at the top and bottom of the combo box drop-down list

Note the artefacts at the top and bottom of the combo box drop-down list

It looks like I am going to have to release it like this, unless someone knows of a better patch. This is very annoying after the months of hard work I have put into the new release. Aesthetics are important for commercial software, especially on the Mac. This could cost me quite a few sales.

I am not on the very latest release of Qt, but apparently this issue would still occur even if I was. Qt/Nokia have announced that they don’t expect to  support Mac OS X 10.6 until they release Qt 4.6, whenever that might be. What use is a cross-platform toolkit that doesn’t support the latest major OSs?

Developer releases of 10.6 have been available for a while – I believe the Qt team should have burnt the midnight oil to make sure they had a release that properly supported 10.6 as soon as it became generally available.  I know that isn’t easy given the size of the Qt framework and Apple’s penchant for secretiveness. But that is the game they are in and that is what I expect. I think they have seriously dropped the ball here, and this is coming from a longtime Qt fan-boy. Perhaps they have spread themselves a bit too thin by moving to LGPL licensing.

I have written this post as a quick heads up to other Qt developers. Thanks to everyone that helped me get this far.

Using a Mac mini for development

mac miniI have been using a Mac mini to port my C++/Qt based code to Mac OS X for the last 3.5 years. This is one of the early PowerPC based Mac minis, upgraded to 1GB of RAM. Being Apple hardware, it is expensive for what you get. But it has served me well. The small form factor (approx 17 x 17 x 5 cm) has also been useful in my cramped office, where I have it attached to the same monitor, mouse and keyboard as my Windows box through a KVM switch. But it is struggling to keep up with PerfectTablePlan’s ever increasing code base. A clean build of the PerfectTablePlan source into a Universal (fat) binary now takes an eye-watering 36 minutes to compile and link on the Mac mini. Building a PowerPC-only debug version still takes nearly half that time. That is painful, even just for occasional porting work.

As my main development environment is Windows, I can’t really justify the cost (or office space requirements) of a Mac Pro. So I decided to buy a new Mac mini, with an Intel Core 2 Duo processor. I did look around to see if I could find one at a discount. However, this being Apple hardware, no-one dares sell  at anything significantly less than Apple’s RRP. I bought the smaller (120GB) disk variant and had the dealer upgrade it to 2GB RAM, which tests on my old Mac mini indicated should be plenty for compiling and linking. I didn’t want to do the memory upgrade myself as I know, from experience with my first Mac mini, that removing the case involves putty knives and some very worrying cracking noises.

I had all sorts of problems trying to get the right cables. Firstly I wanted a Firewire cable so I could copy the set-up across from the old machine to the new machine using Apple’s Migration Assistant software. But it turns out that the old Mac Mini has a Firewire 400 6-pin socket, whereas the new Mac Mini has a Firewire 800 9-pin socket. I ordered a 6-pin to 9-pin Firewire cable cable. Then I discovered that there is more than one type of DVI cable. The old Mac mini was attached to my KVM switch with a DVI-I cable. The new Mac mini only accepts mini-DVI or (via a supplied adaptor) DVI-D. So I ordered a dual link DVI-D to DVI-D cable as well.

Once I had the right cables things went relatively smoothly. The Migration Assistant software copied almost all the apps and data across from the old machine to the new one. It even preserved settings for the apps, e.g. the email accounts in my Thunderbird email client. I just had to re-install XCode (which wasn’t copied across) and rebuild my Qt libraries (to avoid copious warnings due to the fact they had been built with an earlier version of XCode/gcc).

To use the migration assistant you simply:

  1. connect the 2 machines with a Firewire cable
  2. start-up the old machine with the ‘T’ key depresses to put it in ‘Target’ mode
  3. start-up the new machine
  4. follow the on-screen instructions

Nice. If only it was was that easy to set-up a new Windows machine.

A quick test shows that the new Mac mini is nearly 6 times faster at compiling and linking a Universal binary of PerfectTablePlan from scratch[1]:

mac mini performance

The time the new Mac mini takes to compile and link an Intel-only debug release of PerfectTablePlan also compares favourably with a similar build on my Windows 2.13 GHz Intel Core 2 Duo box with 4GB of RAM[2].

mac mini performance 2

This isn’t a fair hardware comparison, as the two machines are using completely different compilers and linkers and the Windows box was running various background services. But it certainly shows that Intel-based Mac minis are worth considering for use as development machines.

[1] The newer machine is using a newer version of XCode/gcc.

[2] The Windows box is using Visual Studio 2005.

Qt to be available for free under LGPL

qtToday Nokia announced that the cross-platform Qt framework is to be released under the LGPL, with no developer licensing fees or royalties. As someone who has been using Qt continuously for the last 9 years, this is of particular interest to me. Especially since the hefty annual renewal fee for my commercial Qt licence is due in a few months.

Here is the email I received from Nokia:

Dear Qt User:

Nokia is pleased to announce that with the release of Qt 4.5 you will be able to use Qt under the Lesser General Public License (LGPL) version 2.1 terms. When released in March 2009, Qt will be made available under three licensing options: Commercial, LGPL and GPL. Prior versions of Qt are not impacted by this announcement.

Nokia is committed to Qt and its continued development. By offering Qt under LGPL version 2.1 license terms alongside today’s licensing options Nokia hopes to:

– facilitate wider adoption of Qt across industries, desktop, web and embedded platforms.

– establish Qt as a de facto standard for application development.

– receive more valuable feedback and increased user contributions to ensure that Qt remains the best-in-class, cross-platform framework.

– extend Nokia’s existing platform commitment to the open source community.

By offering a cost-free LGPL license as well as commercial and GPL licenses to Qt, you can choose the license model that best fits your development requirements.

Irrespective of which license model you choose:

– Qt Software is committed to continuing to provide our customers with the same level of professional support, services and regular releases you have come to expect of Qt Software.

– We will continue to actively develop Qt, and with a greater degree of cooperation with the community through a new contribution model, we hope to make Qt even more valuable to our users.

For more information on the introduction of the LGPL license and what this means for you, please consult the Frequently Asked Questions section on http://www.qtsoftware.com.

Best regards

Tom Miller

Director of Sales

Nokia, Qt Software

I am a big fan of QT. Over the years it has evolved into an extremely polished and comprehensive framework, with: impressive cross-platform capabilities across a wide range of desktop OSs and embedded devices; C++ and Java APIs; excellent documentation and  a wide range of supporting tools (there is now even a cross-platform Qt IDE). The introduction of WebKit also takes Qt some way towards bridging the desktop/web divide. Widely admired by developers, the main stumbling block to Qt’s wider adoption has been the relatively high cost of commercial development licences.

Qt has been available for a while with both commercial and GPL licensing. The commercial version is expensive and the GPL version is free. However, using the GPL means you have to release the source of your own application, which is enough to make it unattractive to the vast majority of commercial software vendors. With the LGPL you can use the Qt libraries for free while keeping your own code proprietary.

So why would Nokia licence Qt under the LGPL? They even have a page on their site saying why they don’t think the LGPL is a good fit for Qt. A commercial licence for Qt is expensive, both in initial purchase costs and annual maintenance. Why is Nokia giving up a fat revenue stream? I am too cynical to believe that it is pure altruism. I guess the Qt licence fees are fairly insignificant to their new owner, Nokia, and they see it as an important strategic step to allow their mobile devices to compete against the free iPhone and Android APIs. Feel free to speculate on alternative motivations in the comments below.

As a commercial Qt licencee I am still working out the full implications of switching to LGPL Qt.

  • Including a copyright notice, the licence agreement and a link to the downloadable Qt source shouldn’t be a problem.
  • Shipping a linker and object files isn’t realistic, so I would probably have to dynamically link Qt. I much prefer static linking to avoid ‘DLL hell’ issues.
  • It isn’t clear whether all the Qt classes and widgets available in the commercial version are available in the LGPL version. Does it include the Qt 3 -> Qt 4 backward compatibility layer?
  • Will I still be able to get decent technical support, or will I need to buy a support contract?

I haven’t had time to assimilate it all yet. But I think a number of trends could make the free LGPL Qt into a big player in the future:

  • The increasing interest in cross-platform tools due to the growing Mac market share and an increasing numbers of mobile devices.
  • The neverending uncertainties about the future of Delphi.
  • The shortcomings of .Net for some types of development, e.g. ‘shrinkwrap’ software.
  • Microsoft’s apparent lack of enthusiasm for MFC and Windows Forms.
  • The many technical strengths of Qt.

It certainly looks like very bad news for directly competing cross-platform technologies such RealBasic and WxWidgets.

Further reading:

PS/ Thanks Nokia (I think)!

A mathematical digression (revisited)

I received two working programs that attempted to solve my ellipse problem. Both were creditable attempts, but neither of them were quite accurate enough for my requirements. One had small (but visible) gaps between the first and last circle and the other didn’t work well for small or large n. However they made me think that a heuristic approach might be workable.

I made a couple of attempts to work out the quartic equations I would have to solve to find the solution analytically. But my brain started to bleed.

After much thinking about it I coded a heuristic approach myself in a day (till 3am!). It works from n=1 to n=100 for variable a/b without noticeable gaps or overlaps for n>7. There is some slight overlapping at n=7 and a/b=1.5. But I can fudge that by changing a/b to 1.6!

The approach is:

  1. use Ramunajan’s formula to work back to a reasonable starting value for b (semi-minor axis)
  2. lay out the n circles
  3. work out the gap/overlap between the first and last circle
  4. if gap/overlap error acceptable, stop, otherwise go to 2

There is also a bit of extra fudging for small n.

I used the secant method to interpolate the values for steps 1,2 and 4. As the functions were all smooth and well-behaved this converged on accurate answers very rapidly (typically 5 or 6 iterations per calculation).

Despite the fact that it is doing 2 levels of iterative calculation, it is surprisingly fast. Even going for high accuracy it takes <1ms for n=50 and <2ms for n=100 on my Windows box. About double that on my old Mac mini. And I can easily cache results in memory for more speed.

You can download and play with the test harness binaries here, if you are so inclined:

Windows binaries (Windows XP or Vista)

Mac binaries (MacOSX 10.3.9 or later)

Both Windows and Mac versions are created from a single set of C++ using the Qt cross-platform toolkit. Note that the timer resolution is 1ms, so times <1ms show as 0ms.

So the next version of my table planner software will have oval tables. As always, there was something I hadn’t though of. I had to do a bit of extra work to calculate the normal to the ellipse circumference (which isn’t the same as the line that joins the ellipse centre and the circumference – as I had initially assumed).

Without calculating normals.

With calculated normals

The commercial value of this feature probably isn’t worth the time I have spent on it. But it will make some of my customers very happy and it was an interesting problem. Part of the reason I set up as a microISV was to do things that I find interesting.

Many thanks to everyone that contributed code or suggestions to the original post.

Nokia to acquire Trolltech (makers of Qt)

trolltechTelecoms giant Nokia are to acquire Trolltech, the company behind leading cross-platform toolkit Qt. As a fan and long time user of Qt this makes me a little nervous. I hope it will lead to more investment in Qt and lower maintenance fees. The opposite could happen of course. It isn’t unknown for a large company to buy a good product and then ruin it (the purchase of Purify by Rational springs to mind). At least I have the full source code for Qt if it all goes to hell in a handbasket. I learnt long ago (the hard way) that you should never depend on a third party libraries if you don’t have the source.