Tag Archives: mac os x

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.

** Update Jan-2022 **

Hammer4mac doesn’t run on recent versions of macOS and seems to have been quietly abandoned by the developer for some time.

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.

First impressions of the Retina 13″ Macbook Pro

macbook pro retinaMy table planner software runs on Windows and Mac. Previously I took a Windows laptop with me when I was out of the office or on holiday, so that I could provide technical support to my customers. But it isn’t (legally) possible to run Mac OS X on Windows, so this made it hard to give Mac customers the best possible technical support. For example I couldn’t send them Mac screenshots or replicate Mac-only bugs from a Windows laptop. However it is legally possible to run both Mac OS X and Windows on a Mac. So I decided to buy a 13″ Retina Macbook Pro for my new laptop, so that I could have access to both OSs when out of the office. I was also attracted by the screen and design of the new Retina Macbook Pro. I choose the 13″ model, rather than than the 15″ model, simply because it is more portable (e.g. more likely to fit in a hotel safe). I also paid to upgrade the SSD from 128GB to 256GB to have room for both Mac OS X and Windows setups. I have now had my Macbook Pro for a few weeks, so I thought I would share my initial impressions.

The good points:

  • The 2560 x 1600 Retina screen is gorgeous, both in terms of sharpness and colour. It makes the display on my old Toshiba Windows laptop look very tired.
  • With a 2.5 GHz Core i5 processor, 8 GB of RAM and an SSD it is very responsive.
  • The aluminium chassis is beautifully designed. Despite being only 19mm thick and 1.6Kgs, it feels very sturdy. The power brick is quite small and light as well.
  • The keyboard is nice. Automatically backlighting the keys in low light is a nice touch.
  • The power cable attaches magnetically. This means it is easy to attach. But, more importantly, accidentally kicking the cable just pops the cable out, rather than the whole machine crashing onto the floor.
  • Gestures work very nicely on the touch pad. For example you can drag two fingers up and down to scroll or tap with 2 fingers to simulate right click.
  • I have Windows and Mac OS X  stored on separate partitions. I can access Window either by booting into Windows or from inside Mac OS X using Parallels (cost approx $80). Being able to access Windows from Mac OS X without a reboot is very useful.
  • The speakers are surprisingly good.

The not so good points:

  • The Macbook Pro is expensive compared to Windows ultrabooks with similar specs.
  • There are a limited number of ports:  2 USB, 2 Thunderbolt, 1 headphone, 1 HDMI and 1 unidentified (SD memory card?).
  • There is no Ethernet port. So if there is no Wifi, you are out of luck.
  • There is no Kensington slot, so you can’t physically lock it down. This is especially annoying given the price.
  • As someone who mainly uses Windows I’m still struggling to get used to the Mac keyboard. For example there is a Backspace key, but no Delete key. Also there is no Home or End key. Worst of all the cursor sometimes  jumps to a different line while I am typing. I have no idea why.
  • Parallels and Windows don’t do a brilliant job of handling the very high resolution of the Retina display. Fonts are sometimes shown very small or very large in Windows. Some applications, such as Keepass v1, looks very fuzzy. Hopefully this will improve with new versions of Parallels and Windows as Retina-like displays become  more common.
  • Not all applications support gestures. For example Firefox on Mac OS X doesn’t support pinch zoom. But I expect this will improve as new versions of applications are released.
  • Not having a built-in DVD drive is a pain. I was able to install Windows 7 by ripping a DVD to a USB stick using Infrarecorder (free). But this didn’t work for Photoshop Elements 11, so I had to download it from the app store, despite having it on DVD.
  • I couldn’t get Windows 8 to work. I installed it into a Bootcamp partition, but when I booted into Windows I just got a mouse pointer and  blue bar down the side of the screen. Apparently Windows 8 is not yet supported by Bootcamp.
  • I am told the graphics performance isn’t great. But I’m not intending to use it for games, so that doesn’t bother me much.

Overall it is an impressive machine and I’m pretty happy with it so far. In particular it is great to able to support Windows and Mac OS X on a single machine. But it does have some annoyances and I wouldn’t have purchased it to just to run Windows. No doubt PC ultrabook manufacturers will have copied its more innovative features fairly soon.

A couple of tips:

  • If you are  in the UK, consider purchasing from John Lewis. They will price match other ‘bricks and mortar’ vendors that have stock. But (at the time I purchased) they were offering 2 years additional warranty. I got them to price match PC World’s £100 off deal. I got £100 refunded and 2 years extra warranty. The service at John Lewis is usually also very good.
  • You probably want to get some form of case or sleeve to protect your lovely and expensive new Macbook. Beware that many of the existing cases are designed for the old Macbook Pros. Consequently they might not be a good fit for the thinner Retina models. I bought this Cool Bananas case. It is a good fit and quite well made. I just wish it had a bit more padding. No doubt more cases and sleeves will become available to fit the new models.

How to sign your Mac OS X App for Gatekeeper

If a prospective customer downloads your software onto Mac OS X 10.8 and it hasn’t been signed, they will see a scary warning:

Not good. To run unsigned software they need to go into Mac OS X Preferences>Security & Privacy>General and change Allow applications downloaded from Mac App store and identified developers to Anywhere:

Or they need to right/Ctrl click and see another scary warning. Double plus not good. This is the new Mac Gatekeeper system in action. Apple being Apple, Gatekeeper defaults to only allowing users to run software they have downloaded off the Internet if it has been signed. This could have a big effect on your conversion rate on Mac. So if you are shipping software for the Mac, you really need to sign it.

Apple fanboys will tell this is a sensible way for Apple to control software quality. A valid certificate shows that your software hasn’t been tampered with and, if it turns out to be malware, Apple can revoke your certificate. The more cynical might see it as a way for Apple to exert even greater control over Mac developers than it already does, while simultaneously extorting $99 per year from each and every one of them. Make your own mind up on that one.

I have now managed to sign my table planner software, ready for its next release. I should have done it months ago. But I expected the process to be so tedious that it has taken me this long to get around to it. And it was every bit as mind-numbingly tedious as I expected trying to find a few useful nuggets amongst the acres of Apple documentation. I found some useful stuff in blogs, but it was quite fragmented. So I have thrown together these notes in the hope that it saves someone else a few hours going round in circles. Note that I am not currently submitting my software to the Mac App Store, so I don’t cover that here. Also my software is developed in C++/Qt using Qt Creator, rather than Objective-C/Cocoa using XCode, and my approach reflects that.

1. Sign up for Apple Developer Connection ($99 per year). Doesn’t matter if you already paid through the nose for a Windows authenticode certificate. Gatekeeper only accepts Apple certificates, so you have no choice. On the plus side, you do get other benefits, including downloading new OS upgrades for free.

2. You need Mac OS X 10.8 so you can test that your signing works. If you have an Apple Developer Connection subscription, you can download 10.8 for free (get a code from the ADC downloads area and using it in the Mac App Store). I found the upgrade from 10.6 to 10.8 was surprisingly painless (Microsoft eat your heart out).

3. Request your Apple certificates and install them into your Keychain. You can do this from Xcode (instructions here). You may need to upgrade Xcode to a recent version.

4. Use the codesign command line tool to sign:

  • Every framework in your .app bundle
  • Every plugin in your .app bundle
  • Your .app file

I believe you can do this as part of your Xcode build. But I prefer a shell script. For example:

echo --sign frameworks --
codesign --force --verify --verbose --sign "Developer ID Application: <yourID>" <yourApp>.app/Contents/Frameworks/QtCore.framework/Versions/4/QtCore
codesign --force --verify --verbose --sign "Developer ID Application: <yourID>" <yourApp>.app/Contents/Frameworks/QtGui.framework/Versions/4/QtGui
codesign --force --verify --verbose --sign "Developer ID Application: <yourID>" <yourApp>.app/Contents/Frameworks/QtNetwork.framework/Versions/4/QtNetwork
codesign --force --verify --verbose --sign "Developer ID Application: <yourID>" <yourApp>.app/Contents/Frameworks/QtSql.framework/Versions/4/QtSql
codesign --force --verify --verbose --sign "Developer ID Application: <yourID>" <yourApp>.app/Contents/Frameworks/QtXml.framework/Versions/4/QtXml
codesign --force --verify --verbose --sign "Developer ID Application: <yourID>" <yourApp>.app/Contents/Frameworks/Qt3Support.framework/Versions/4/Qt3Support

echo --sign plugins--
codesign --force --verify --verbose --sign "Developer ID Application: <yourID>" <yourApp>.app/Contents/Plugins/accessible/libqtaccessiblecompatwidgets.dylib
codesign --force --verify --verbose --sign "Developer ID Application: <yourID>" <yourApp>.app/Contents/Plugins/accessible/libqtaccessiblewidgets.dylib
codesign --force --verify --verbose --sign "Developer ID Application: <yourID>" <yourApp>.app/Contents/Plugins/bearer/libqcorewlanbearer.dylib
codesign --force --verify --verbose --sign "Developer ID Application: <yourID>" <yourApp>.app/Contents/Plugins/bearer/libqgenericbearer.dylib
codesign --force --verify --verbose --sign "Developer ID Application: <yourID>" <yourApp>.app/Contents/Plugins/codecs/libqcncodecs.dylib
codesign --force --verify --verbose --sign "Developer ID Application: <yourID>" <yourApp>.app/Contents/Plugins/codecs/libqjpcodecs.dylib
codesign --force --verify --verbose --sign "Developer ID Application: <yourID>" <yourApp>.app/Contents/Plugins/codecs/libqkrcodecs.dylib
codesign --force --verify --verbose --sign "Developer ID Application: <yourID>" <yourApp>.app/Contents/Plugins/codecs/libqtwcodecs.dylib
codesign --force --verify --verbose --sign "Developer ID Application: <yourID>" <yourApp>.app/Contents/Plugins/graphicssystems/libqtracegraphicssystem.dylib
codesign --force --verify --verbose --sign "Developer ID Application: <yourID>" <yourApp>.app/Contents/Plugins/imageformats/libqjpeg.dylib

echo --sign app--
codesign --force --verify --verbose --sign "Developer ID Application: <yourID>" <yourApp>.app

I do this in a build shell script that automates the whole process of creating a .dmg for download. I’m not sure if the order you sign the components in is important.

Note that:

  • <yourID> is the ID on your certificate (in my case “Oryx Digital Ltd”).
  • For frameworks you sign the folder, not the file.
  • Any changes to the .app bundle after signing may invalidate the signature (that is kind of the point).

5. Verify the  signing of the .app file. For example:

codesign -vvv -d <yourApp>.app

6. Package your .app into a .dmg, .zip, .pkg or whatever other format you use to install it (I believe .pkg files might require additional signing with a different certificate).

7. Make sure your Mac OS X 10.8 machine is set to the default Gatekeeper setting.

8. Download your software onto Mac OS X 10.8 and check if the scary warning has gone away.

9. Pray that Apple doesn’t decide to revoke your certificate at some point for an infraction, real or imagined.

Until you have released a signed version you can put up a warning with some simple Javascript, for example:

Further reading:

http://www.hardcoded.net/devlogs/20120407

http://www.mactech.com/articles/mactech/Vol.24/24.11/CodeSigning-GetUsedtoIt!/index.html

http://www.macworld.co.uk/macsoftware/news/?newsid=3338078

http://support.apple.com/kb/HT5290

http://www.macworld.com/article/1165408/mountain_lion_hands_on_with_gatekeeper.html

http://developer.apple.com/library/mac/#documentation/ToolsLanguages/Conceptual/OSXWorkflowGuide/CodeSigning/CodeSigning.html

http://developer.apple.com/library/mac/#documentation/ToolsLanguages/Conceptual/OSXWorkflowGuide/DistributingApplicationsOutside/DistributingApplicationsOutside.html

Qt related:

http://lynxline.com/submiting-to-mac-app-store/

http://www.digia.com/en/Blogs/Qt-blog/Pasi_Matilainen/Dates/2012/4/How-to-Publish-Qt-Applications-in-the-Mac-App-Store/

http://comments.gmane.org/gmane.comp.lib.qt.user/637

Java related:

http://blogs.oracle.com/talkingjavadeployment/entry/java_applications_and_gatekeeper

http://www.ej-technologies.com/products/install4j/whatsnew51.html

Thanks to Jonathan of DeepTrawl and Stephane of LandlordMax for some useful pointers.

************** Update **************

Things have changed again for Mac OS X 10.9/10.10. See this post for an update.

Is it worth advertising Mac software on Google Adwords?

I learnt a long time ago that people will happily click on totally irrelevant pay per click ads. For example, if you bid on “seating plan” I can assure you that a significant percentage of people searching for “boeing 747 seating plan” will happily click on your ad titled “wedding seating plan”. They won’t buy anything, as they aren’t interested in wedding seating plans, but you still have to pay for each click. You can stop your ad showing to these searchers by adding “boeing” and “747” as negative keywords. Problem solved.

But what do you do if you are selling software that only runs on Mac OS X? The vast majority of searchers are running Windows. Indiscriminate clicks by them could quickly turn your Adwords ROI negative. In your Adwords campaign settings you can choose to only show ads on desktop computers and laptops. But you can’t choose the operating system.

As discussed above, putting “Mac” in the title is unlikely to be enough. You can’t use negative keywords, because the vast majority of Windows users searching for, say, backup software will type “backup software” not “Windows backup software”. You can just bid on searches containing keywords “Mac”, “Apple” or “OS X”, but will this be enough? My general advice to Mac only software vendors was to avoid Adwords, unless the ticket price of their software was in the hundreds of dollars. But, as my software runs on both Windows and Mac, I didn’t have any data to back this up.

Recently I got some data on Adwords clickthrough rates for a Mac only app (www.puzzlemakermac.com) by Hokua Software. They have kindly allowed me to share the data.

Initially they bid on generic keywords, such as “crossword maker” and ran ads such as the following with “Mac” displayed prominently in the title:

The results from analytics: 60% of the people clicking on the ads were on Windows and 40% on Mac.

Then Google banned them from the word “Mac” in their ads (it is possible to get this reversed with the express permission of Apple, but I don’t know how likely they are to grant this). So they switched to “OS X” in the ad, which hasn’t been blocked (yet).

The results from analytics: 73% of the people clicking on the ads were on Windows and 27% on Mac.

Then they restricted their bids to Mac targeted keywords such as “mac crossword maker”.

The results from analytics: 23% of the people clicking on the ads were on Windows and 73% on Mac. But there was a big drop in the number of impressions.

I think it is going to be almost impossible for anyone to get a return from Adwords when the majority of their clicks have no chance of generating a sale. So only bidding on Mac specific keywords seems to be the way to go. But there will still be a significant number of wasted clicks from Windows users. Also any Mac users who don’t use the appropriate keywords won’t see your ad. Consequently the return on time and money invested is likely to be a lot lower than Windows, cross-platform and web developers can expect. If you have a Mac only product with: a high ticket price product, well-defined keywords and limited competition, it might be worth trying Adwords. But otherwise it is probably better to wait and see if Google release OS targeting.

Of course, you could always use one of the free Adwords vouchers that Google are handing out like confetti (I get one every month in my PC Pro magazine) and try for yourself. This is how Hokua software got the results above. If you do, I would be interested to know how your results compare.

App stores set to dominate future software sales?

Following the success of the iPhone app store (over 6 billion downloads to date), app stores are becoming more and more of a feature of the software landscape. In case you missed it, Apple announced yesterday that there will be an App Store for Macs  ‘within 90 days’. In summary:

  • The Mac app store will be tightly integrated with Mac OS X, including automatic install and update.
  • There will be restrictions on technology, for example Java apps will not be allowed.
  • Apple will keep 30% of any revenue from sales.
  • $99/year subscription for developers.
  • Developers will still be able to sell their software outside the App store.

It is easy to see why Apple would want to do this:

  • A potentially huge new revenue stream from third party Mac software sales.
  • They get even more control over the customer experience.

And this could have advantages for Mac users:

  • Simpler payment and installation.
  • Screening out of low quality apps and malware.

And potential advantages for Mac developers:

  • Mac users might buy more software if it is easier to do so.
  • One main channel to concentrate your marketing efforts on.
  • Some of the boring infrastructure of selling software (licensing, shopping cart etc) can be taken care of by Apple.

But the disadvantages are all too obvious:

  • Your app could be rejected outright. And you won’t know until you submit it for approval. Apple are judge, jury and executioner. The iPhone app store has been infamous its capricious and opaque approval process.
  • 30% is a huge chunk of revenue. Typical payment processors take 5-10% of revenue. Where the new app store cannibalises existing sales (and it is hard to see that it won’t) vendors will lose 20-25% of existing sales revenues.
  • New apps and updates will be delayed by days or weeks as they go through the app store approval process.
  • A single centralised app store is likely to make it harder for niche/long-tail apps to make any sort of living. Certainly this is what seems to be happening in the iPhone App store.
  • Apple are control freaks and have traditionally taken a rather heavy handed approach with developers, including the liberal use of NDAs. The app store will give them even more control.

And worse might follow:

  • Apple makes a lot of their money from selling over-priced hardware. It may be in their interest to drive software prices down so they can sell more hardware. $5 is considered expensive in the iPhone App Store.
  • This could be the first step to making Mac OS X a closed system, like iPhone, where only Apple approved apps can be installed.

I guess they can’t piss off developers too much – a computer without third party applications isn’t going to be very attractive to customers. But I am finding it hard to work up any enthusiasm for a Mac app store. If it is successful I can either be in the store and give up a lot of freedom and cannibalize exisiting sales at a much lower margin, or stay out and be shut out of a large chunk of the market. It isn’t an attractive choice. As my app is written in C++/Qt, rather than Objective-C/Cocoa, I am not even sure that it will be eligible for inclusion in the store. I could just abandon Mac OS X, but Microsoft is also rumoured to be working on their own app store (despite the failure of DigitalLocker). That is a truly terrifying prospect given the awfulness of their ‘Works with Vista’ approval process (I speak from personal experience).

Suddenly web apps are looking more interesting.

Free computer wallpaper

I got bored of looking at the standard Windows and Mac desktop wallpaper, so I decided to re-purpose some of the photographs I have taken on my travels. I have created standard and widescreen versions. They should be high enough resolution even for most developers’ monitors. Happy Christmas.

Licensing

You can freely use these images as wallpaper on your computer. However they may not be modified, used for any other purpose or distributed (except via http://www.successfulsoftware.net) without my explicit written permission. I retain the copyright and all other rights to these images.

Instructions

Left click on a thumbnail of the appropriate size/aspect-ratio for your monitor.

Right click on the full-size image and select:

  • FireFox: Set as desktop background
  • Internet Explorer: Set as background
  • Safari: Use image as desktop picture

1920 x 1200 wallpaper

These images are suitable for wide screen monitors (aspect ratio 8:5) including:

  • 1920 x 1200
  • 1680 x 1050
  • 1440 x 900
  • 1280 x 800

Stirling Falls, New Zealand.

Window reflection.

Peak 43, Nepal.

Palm, Queensland, Australia.

Lenticular clouds near Mount Sefton, New Zealand.

Kalahari sand at sunset, Namibia.

Heron Island, Queensland, Australia.

Waves, Hawaii.

A MiG-29 Fulcrum performing the 'cobra' manoeuvre.

Dead Vlei, Namibia.

Dead Vlei, Namibia.

Boyd Falls, New Zealand.

Great Barrier Reef, Queensland, Australia.

Great Barrier Reef, Queensland, Australia.

Aquarium, Plymouth, UK.

1600 x 1200 wallpaper

These images are suitable for standard monitors (aspect ratio 4:3) including:

  • 1600 x 1200
  • 1152 x 864
  • 1024 x 768
  • 800 x 600

Stirling Falls, New Zealand.

Window reflection.

Peak 43, Nepal.

Palm, Queensland, Australia.

Lenticular clouds near Mount Sefton, New Zealand.

Kalahari sand at sunset, Namibia

An MiG-29 Fulcrum performing the 'cobra' manoeuvre.

Boyd Falls, New Zealand.

Great Barrier Reef, Queensland, Australia.

Aquarium, Plymouth, UK.

Notes

Creating wallpaper wasn’t as easy as I thought (nothing ever is). You need images that are in landscape format, are not too saturated, contrasty or busy and are cropped and resized to exactly the right width and height. Thankfully I had some tools to help – I used PicCrop to do the cropping, BatchPhoto for batch creation of the thumbnail images, Xplorer2 for batch file renaming and Photoshop Elements for everything else. Some of the images are only available in wide screen format as they didn’t work as well in a 4:3 format.

All the photographs were taken by me with a Minolta Dynax 7D digital camera or scanned from slides taken by me with a Minolta Dynax 700si. Goodbye Minolta cameras, I miss you.

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.