Category Archives: MacOSX

Qt is broken on macOS right now

Let me say up front that I am a big fan of the Qt framework. I have been working with it continuously since the late 90s. Both of my commercial products (PerfectTablePlan and Hyper Plan) are written on top of Qt. But Qt is quite broken on macOS right now. In fact I struggled to find a version of Qt 5 that supported recent versions of macOS and didn’t have a showstopper bug. I must have wasted a couple of weeks grappling with these issues. I am putting my notes here in the hope that they help someone else.

Here are the 4 bugs in macOS version of Qt that have causing me the most headaches:

Qt Version
bug v5.9.6 v5.10.1 v5.11.0 v5.11.1 v5.11.2
QFontDialog broken (link) ok ok ok ss ss
QStaticText::size() returns wrong value for rich text
with line breaks
ss ss ok ok ok
widgets such as QTableWidget do not repaint correctly (link) ok cwa cwa cwa cwa
default QComboBox size is incorrect (link)
ok ok cwa ok ok

Where:

ok = bug not present.

cwa = bug present, but can workaround.

ss= bug present, making release unusable for me (showstopper).

Consequently Qt 5.11.0 is the only usable release on macOS for me and I have to kludge my way around two quite nasty bugs. While the QStaticText issue is fairly obscure (but important for me), how in the hell did QFontDialog get completely broken without anyone noticing? And then not get fixed for two whole releases?! I also know other developers who are having to stick with earlier versions of Qt due to the bugginess of the recent versions of Qt on macOS. This isn’t good enough.

Thankfully the recent versions of Qt are much more solid on Windows.

Getting Qt 5.9 working on Windows (eventually)

I have had Qt 5.5 and 5.6 installed on my development machines for some time. Now that I have purchased a new Mac development box (an iMac with a lickably beautiful 27″ screen) I thought it was a good time to update to a more recent version of Qt. I went for Qt 5.9, rather than Qt 5.10, as 5.9 has been designated as an LTS (long term support) release. Upgrading turned into a real chore. I am quickly writing it up here in the hope that it helps someone else, and as a reminder to myself a few years down the line.

I like to build Qt from source. Because then I know it was built using the same compiler, headers, SDK etc as I am using to build my product. And I have more control over how Qt is configured. Also I can patch the source and rebuild it, if I need to. But I have had problems building Qt on Mac before. So I decided to install the pre-built binaries on my new Mac. I installed the latest version of XCode and then the Q5.9.4 binaries. This was a couple of big downloads, but it all went pretty smoothly.

I successfully built Qt 5.5 from source on my Windows machine previously, so I decided to try that for Qt 5.9. I have Visual Studio 2010 installed. This isn’t supported for Qt 5.9.4, so I downloaded Visual Studio 2017. I unzipped the Qt source into C:\Qt\5.9.4, ran ‘x86 native tools command prompt for VS 2017’, made sure Python and Perl were in the path and then:

cd C:\Qt\5.9.4

set QTDIR=C:\Qt\5.9.4\qtbase

set PATH=%QTDIR%\bin;%PATH%

configure -opensource -confirm-license -opengl desktop -nomake tests -nomake examples -no-plugin-manifests -debug-and-release -platform win32-msvc -verbose

nmake

Note that you are told by the nmake script to do nmake install at the end of this. But it tells you somewhere in the Qt Windows documentation not to do this, unless you have set the prefix argument (confusing, I know)

The build failed part way through making qtwebengine. Something to do with a path being too long for Perl or Python (I forget). It seems to be a known problem. Odd as the root path was just C:\Qt\5.9.4. I don’t need qtwebengine at present, so I deleted everything and tried again with -skip qtwebengine:

configure -opensource -confirm-license -opengl desktop -skip qtwebengine -nomake tests -nomake examples -no-plugin-manifests -debug-and-release -platform win32-msvc -verbose

nmake

It seemed to complete ok this time. But using this version of Qt to build Hyper Plan I got an error:

Unknown module(s) in QT:svg

On further examination the SVG DLL  had been built, but hadn’t been copied to the C:\Qt\5.9.4\qtbase\bin folder. Similarly for a lot of the other Qt DLLs. I couldn’t find any obvious reason for this looking through logs, Stackoverflow and Googling. I could possibly do without the SVG functionality, but I wasn’t sure what else was broken. So I decided to give up on bulding from source on Windows as well.

I download the Qt 5.9.4 binaries for Visual Studio 2017. This seemed to go ok, but then I discovered that I could only build a 64-bit application from these. No 32-bit version was available for Visual Studio 2017. Many of my customers are still on 32 bit versions of Windows. So I need to be able to ship my product as a 32 bit executable + DLLs[1].

So I uninstalled Visual Studio 2017 and installed Visual Studio 2015. I then got an error message about Visual Studio 2017 redistributables that I hadn’t uninstalled. So I had to uninstall those and run a repair install on Visual Studio 2015. That seemed to work ok. So then I download the 32-bit Qt 5.9.4 binaries for Visual Studio 2015. I had to download these into a different top level folder (C:\Qtb), so as not to risk wiping existing Qt installs that I had previously managed to build from source.

Eventually I managed to build Hyper Plan and PerfectTablePlan on Mac and Windows. What a palaver though! Qt is an amazing framework and I am very grateful for everyone who works on it. But I wish they would make it a bit easier to install and upgrade! Has anyone actually managed to get Qt 5.9 built from source on Windows?

[1] I don’t bother shipping a 64-bit executable on Windows as the 32-bit executable works fine on 64-bit versions of Windows (my software doesn’t require excessive amounts of memory). I only ship a 64-bit executable on macOS as almost no-one uses 32-bit versions of macOS now.

Bundlefox review

I have been using bundles and 1-day sales as a useful way to increase the exposure for my visual planning software. I have had positive experiences with BitsDuJour, Macupdate and BundleHunt. Once you put your software in one bundle you inevitably get approached by people who run other bundle promotions. I was approached by Bundlefox and agreed to put Hyper Plan in their Mac software bundle. I wish I hadn’t. It has been a pretty miserable experience from start to finish. In brief:

  • I never knew when the promotion was going to start or end. I was told it was going to start on 27th February, but it eventually started on 20th April. It was supposed to run for 3 weeks, but actually ran for 6 weeks. This is a problem, because it means you can’t put your software in other sale or bundle that require an exclusive discount.
  • Communication was poor. They generally took several days to reply to emails.
  • The number of licenses sold was very low, especially compared with sales of Hyper Plan on BundleHunt.
  • Worst of all, they only paid me 60% of what I was expecting per license. When I queried this they emailed me back “It’s **% revenue share after fees, most of the sales came in through affiliates and we had to pay them off before sharing the revenue”. I went back through their emails and their ‘Vendor Manual’ and there is no mention of affiliate fees being subtracted. It just says “You would receive a percentage of the total payments received for the bundle minus PayPal fees”. In fact I had emailed them “So if you sell 2000 bundles for $12 of which 500 choose Hyper Plan, I get **% of $12×500 = $***?” and they replied “Your calculation is correct”. I feel deceived.
  • The low number of licenses sold and the low payout per license means that it wasn’t worth the effort to setup.

I don’t know what Bundlefox are like to deal with as buyer, but I recommend vendors give them a wide berth.

Hammer For Mac static website generator

I prefer static websites to a CMS for simple product websites because:

  • Static websites are fast.
  • I have more low-level control over the HTML/CSS.
  • I don’t have to worry about the very-real threat of a CMS being hacked.

Obviously writing every page separately in raw HTML/CSS would go against one of the cardinal rules of development, Don’t Repeat Yourself. But you can avoid this using a static website generator such as Hammer for Mac.

hammer

Hammer uses a simple syntax embedded in HTML comments to ‘compile’ a website from source files. I have now used Hammer to create several static HTML/CSS websites, including my perfecttableplan.com and hyperplan.com websites.

I like the simple syntax of Hammer. For example:

I can put the HTML for a page header in an _header.html file and then each page just needs to start with:

<!-- @include _header.html -->

I can define and use variables:

<!-- $current_year 2016 -->
..
<p>Copyright <!-- $current_year -->.</p>

And I can let Hammer work out relative paths:

<img src="@path image.png" />

If Hammer can’t make sense of a source file (e.g. it can’t find the image file), it generates a compilation error.

Because everything is text based I can easily manage all the source in a version control system. Also, if I have to move away from Hammer, it should be relatively straightforward to change the syntax to another static generator (or even write a replacement for Hammer!).

Overall I like Hammer. But it does have a number of shortcomings:

1. The user interface is very limited. Hammer shows you a list of source files and you can click on a source file to see the compiled version or edit the source. But the source files are listed in the order they were edited and you can’t filter or sort the list. This seems such a simple and basic feature, that I can’t understand why the developers have omitted it.

2. Hammer takes a dumb, brute force approach to compilation. If you change any file in a source folder, it recompiles *everything*, without checking if other source files include that file. This is a pain if you have 100+ source files. Surely it wouldn’t be that hard to work out which files depend on which and only recompile the files that need recompiling?

3. You can’t nest variables. For example you can’t do this:

<!-- $current_year 2016 -->
<!-- $copyright_message Copyright <!-- $current_year --> -->

This might sound minor. But it limits the expressiveness of variables significantly.

4. The vendor doesn’t do email support. If you want to communicate with them you have to use Slack or Twitter. I am old fashioned, I like email.

5. It only runs on Mac OS X (the clue is in the name).

At one point Hammer looked like abandonware, but owner riothq.com sold it to beach.io and active development has resumed.

Currently Hammer is priced at £15.39 (and presumably some round number of US dollars). That seems way too cheap. I wish they would price it a bit higher and fix some of the issues above.

 

Signing Qt applications for Mac OS X 10.9.5 and 10.10

I have written previously about signing Qt applications for Mac OS X. It all worked fine until I upgraded to Mac OS X 10.9.5, which broke my signing script. Those Apple chaps do love to break stuff. Grrr.

The problem appears to be that the directory structure of the app bundle has changed and the Qt4 macdeployqt command does not conform to the new layout (I believe this is also the case for Qt5). Oh joy. I managed to work out how to get it working again after a bit of digging around. The good news is that Apple have also made the codesign command easier with a --deep option to traverse and sign the whole bundle in a single command. About time.

So here is the basic process to build and sign your Qt .app on the latest versions of Mac OS X:

# deploy Qt frameworks into .app bundle
$QTDIR/bin/macdeployqt <your_app>.app -verbose=1
# optionally delete unwanted framework and plugin folders, e.g.:
# rm -f -r <your_app>.app/Contents/Frameworks/QtDeclarative.framework
# rm -f -r <your_app>.app/Contents/PlugIns/sqldrivers
# correct .app bundle structure
python rebundle.py $QTDIR <your_app>.app
# sign .app bundle (including frameworks and plugins)
codesign --deep --force --verify --verbose --sign "Developer ID Application: <your developer id>" <your_app>.app
# the 2 lines below are just for verification/diagnostics
otool -L <your_app>.app/Contents/MacOS/<your_app>
codesign --verify --verbose=4 <your_app>.app

(Sorry about the small font, but I wanted to avoid confusing line wraps).

I then invoke DropDmg to create a .dmg image file complete with licence and background image. This is all stuck it all in a bash script, which I can pretty much forget about it (until Apple break something else).

In the above rebundle.py is a Python script  written by some public spirited individual that can be downloaded from github (thank you, ‘kingcheez’). Note that you can just find and replace all the ‘5’ characters in the script by ‘4’ if you are still using Qt4.

The first time I ran my script I ended up with a whopping 50MB .app file. It turns out that the cp -r commands in my script don’t preserve symbolic links. So you end up with 3 copies of each framework library. You can avoid this by using cp -R instead.

On the subject of signing for Mac, Apple recently sent out an email stating:

Signatures created with OS X Mountain Lion 10.8.5 or earlier (v1 signatures) will be obsoleted and Gatekeeper will no longer recognize them. Users may receive a Gatekeeper warning and will need to exempt your app to continue using it. To ensure your apps will run without warning on updated versions of OS X, they must be signed on OS X Mavericks 10.9 or later (v2 signatures). … Apps signed with v2 signatures will work on older versions of OS X.

So you are going to have to start signing using 10.9, whether you like it or not.

How to build Qt 4.8.5 on Mac OS X 10.9

I prefer to build Qt from source. I have been trying to build Qt 4.8.5 on Mac OS X 10.9 (Mavericks). I managed in the end, but it took a few tweaks. Online information about how to do this was fragmentary, so I am documenting it here in case it is useful to someone else.

1. Webkit doesn’t build. I don’t need it so I disabled it using configure option:

-no-webkit

2. The corewlan plugin doesn’t build. I don’t need it (I think, I’ve never heard of it before) so I disabled it using this fix from stackoverflow.

3. The TIFF image format plugin doesn’t build. I don’t need it so I disabled it using configure option:

-no-libtiff

My final configure command was:

./configure -nomake demos -nomake examples -debug-and-release -no-multimedia -no-audio-backend -no-phonon -no-phonon-backend -no-gif -no-openssl -no-webkit -no-libtiff

There will be lots of warnings that Qt 4.8.5 isn’t compatible with Mac OS X 10.9. But you can ignore these (or comment out the warning in the appropriate Qt header file).

I have done some brief experiments and it seems to work ok. Hopefully there will be a Qt 4.8.6 that fixes these issues. Note that you also need to make some tweaks to your application code. See:

Fixing Qt 4 for Mac OS X 10.9

** UPDATE April-2014 **

Qt 4.8.6 has been released. This appears to build fine on Mac OS X 10.9.

Fixing Qt 4 for Mac OS X 10.9

Mac OS X 10.9 (Mavericks) was released yesterday. And those nice people at Apple made it free, so you can be sure lots of people are downloading it. However Qt 4 apps look at bit strange on the new OS. Look at the text alignment in these buttons:

buttons1The text isn’t centre aligned. It doesn’t look like much of an issue out of context. But it looks wrong when you look at a whole UI. The good news is that there is a simple fix:

#ifdef Q_OS_MACX
    if ( QSysInfo::MacintoshVersion > QSysInfo::MV_10_8 )
    {
        // fix Mac OS X 10.9 (mavericks) font issue
        // https://bugreports.qt-project.org/browse/QTBUG-32789
        QFont::insertSubstitution(".Lucida Grande UI", "Lucida Grande");
    }
#endif

You need to place this code in your main() before creating your QApplication. For more details see this bug report.

With the fix the buttons look like this:

buttons2Much better! There are some console warnings:

CoreText performance note: Client called CTFontCreateWithName() using
name "Lucida Grande" and got font with PostScript name "LucidaGrande". 
For best performance, only use PostScript names when calling this API.

I am not sure how how significant these are.

I have also found that updating to Qt 4.8.5 fixes a printing crash bug in my table plan software. This crash happened when rotated pixmaps were printed from Mac OS X 10.8.

I have seen on forums that Qt 5 is completely broken on 10.9. But I don’t know if that is true.