Starcraft 2 hang on Mac 10.6.5 fix

Been playing a lot of Starcraft 2 lately. Great game, and works okay on Macbook Pro (on low settings). Just upgraded OSX to 10.6.5 and started getting the game freezing up on the login screen. I think Apple have been doing some driver optimisation work.

You can fix this by restarting your Mac in safe mode. (23-Jan-10: There is an Apple help page). You do this by restarting your machine and holding down the shift key whilst it restarts (i.e. from power on). This apparently clears out the OS caches. This takes about 5-10 minutes and you'll see a grey loading bar under the apple on the white loading screen. Once you've got into OSX just restart your machine again (in normal mode) and everything should be fine.

You'll notice that the game is considerably faster now. Quite why the graphics drivers have been so bad for so long would be an interesting question for Apple. I can now run at full res on my second monitor and with medium texture settings. I tried medium settings for everything but the framerate was awful. It is a big visual improvement over everything on low previously.

21-Nov-2010: Another thing you might try, after restarting in safe mode, if you are still having issues, is to run the Starcarft 2 "Repair" application. You can find this in the directory: Applications/Starcraft II/Support. Not sure what this does entirely, but it should ensure that everything is up to date and correct.

(23-Jan-2010: Added link to Apple safe mode help. Thanks "Anonymous"!)

ClanLib 2.2 on Mac OSX 10.6

These are just some notes on building the new version of ClanLib, 2.2, on Snow Leopard. The XCode version of ClanLib using frameworks is pretty broken and hasn't been maintained in some time. It also doesn't look the developers will fix this any time soon. To quote some of the issues:

[...] The 0.9 code base is partly based on 0.8 which already had Mac support, so most of the module are trivial to fix into compiling again. The main porting issue is clanDisplay+clanGL where the window management and AGL context management code needs to be updated. Most of that can once again be taken from 0.8 and updated from that point forward (the code might even already be in 0.9 in a broken state - haven't checked), but you might also just find it easier to rewrite parts of that platform specific code.

In general the code in ClanLib is very modular in the sense that the Win32, X11 and OSX code is usually cleanly separated so porting is mostly just a matter of finding the equivalent OS X functions. Unfortunately when I originally did the OS X port, I mainly relied on the Carbon API mixed with some posix stuff (pthreads mainly) and I hear Apple removed support for Carbon in 64 bit OS X. Having virtually no experience with Objective C or Cocoa I do not know how difficult it is to switch to the equivalent Cocoa functions.

One last issue regarding OS X support is that I personally rely on a simple program called scan.cpp that reside in the Setup/OSX directory which generates a makefile for my purposes. The reason I bring this up is because that while there exist a XCode project, it is currently out of date. It is probably just a matter of bringing the source files into sync to get that project back and operational, but I am personally so allergic to the IDE of XCode that I reverted back to my makefile generator when I ported clanCore and clanNetwork to Mac in 0.9. You are naturally free to fix this project (which officially is the way we tell users to build 0.8 for Mac), but I will have to stay on the makefile myself simply because Apple changed the XCode project file format and my ancient G4 Powerbook with OS X 10.3.9 on it cannot read it after you update it. [source]

And:

I forgot to mention that we will naturally gladly update the framework bundles for any dependency library used by ClanLib. The only problem is that I somewhat forgot how we built them and at least at the time the documentation on library framework bundles provided by Apple was somewhat limited.

Since I do not know how much experience you have with building framework bundles I'll just tell you what I know and hopefully you can use that for something. 

Technically a library framework bundle is simply a normal dynamic library arranged in a certain directory structure (just like application bundles are just directories). In traditional unix environments (BSD, linux, etc.) the include files are placed in /usr/include/ClanLib-0.9 and the dynamic libraries in /usr/lib. But for a framework library those same files are placed in ~/Library/Frameworks/LibraryName/Headers and ~/Library/Frameworks/LibraryName/LibraryName.

To port any library to an OS X library bundle is therefore a "simple" task of simply taking the header files and the output dynamic library and place them in this directory structure. Unfortunately it seems the linker in OS X is rather dumb (at least in 10.3) and requires the dynamic library file to built directly into this directory structure. If you want more details on how to do this manually outside XCode, try take a look at the scan.cpp program that came with ClanLib.

An easier option may be to simply recreate the makefile for the dependency library in XCode. Using this strategy will ensure that the framework bundle is at least correctly built, but great care must be taken to ensure that it is the same source files and defines that are used for the build. I think the current framework bundles available on the website were built using this strategy.

Finally we might be lucky that someone else already did create an OS X framework bundle for some of our dependency libraries. Googling for that first wouldn't hurt. [same source as above]

make

There are a few compilation errors with ClanLib 2.2 out of the box for Mac since it hasn't been maintained in a while. Anything inside #ifdef __APPLE__ is a little stale. Also, as stated, there is no support for certain features, like joystick input.

XCode Project

To fix the Mac issues, the easiest way (for me anyway) is to fix the XCode project. Source code is checked into the Gameres project. Also, on the Mac it seems that OpenGL is only supported via a framework, and I'd like to use OpenGL.

Dependencies are as follows. Apologies if I make any mistakes, these are vague notes from my install. We need to make everything 32-bit as ClanLib is 32-bit (like Allegro). So when you compile the following libraries do:

• ./configure CFLAGS="-arch i386"
• make
• sudo make install
• make clean

Libraries required by ClanLib. You can get these from the download page (in case you need binaries of the same versions).

• libxml2: This is the XML library used by fontconfig. You'll have make this from source as the precompiled Mac binaries install as a framework.
• fontconfig: I installed version 2.8.0. This required libxml2.
• freetype2: I got version 2.4.1 of this font library.
• libpng: I have version 1.4.3 of the PNG library. There seem to be some serious bugs with earlier versions so make sure you have 1.4.3 or later.
• libjpeg: I got JPEG library version 8b (of 16-May-2010).
• pcre: Regular expression library version 8.10.

Now, if installed at the default location, you should have some includes and libraries in /usr/local. I may add the binaries to Gameres at some point.

After a few hours work I managed to fix up the project and get it compiling and linking. It is currently untested and no doubt missing features.

Rapping backwards

Clever rap video. Good work!

Using Allegro 4.4 on Mac

Building

I have Macbook with Snow Leopard 10.6.2 installed and Allegro 4.4.1.1. I did have some hiccups with Allegro 4.4.0.1. Not sure if this was my fault or the distro as I'm still newish to the Mac and the Allegro Mac instructions are a bit dated.

I first tried building Allegro as a framework, but this doesn't work as I think it should. If you include a framework using: #include "Allegro/allegro.h", the internal Allegro files don't prefix with the framework name "Allegro". So, you end up adding the framework path, which is pointless, so you may as well just compile Allegro in /usr/local and link it from there.

Get Allegro (I used 4.4.1.1). Unzip. I have cmake 2.8. In the Allegro directory :-

• mkdir build
• cd build
• cmake ..
• sudo make install
• make clean

Dependencies:

• OpenGL - included in OS.
• libpng, zlib and vorbis - These can be downloaded and installed as standard libs in /usr/local. I don't bother with fink or Macports as I don't want the clutter. I want everything to work "natively". There are some details under the pygame build instructions.

So you should now have a working copy of Allego in /usr/local/include and /usr/local/lib, with some executable utilities in /usr/local/bin.

From the mailing list it appears that you can only compile Allegro as a 32 bit library, there is no 64 bit support so any libraries or frameworks and the dependent libraries will have to be 32 bit. Leopard default is 32 bit. Snow Leopard default is 64 bit.

Creating project in Xcode

• Create a new command-line C++ tool project.
• Paste in the GL example.
• Add /usr/local/include to the header search paths in project settings.
• Add the following frameworks to "Link with Binary Libraries" :
• Cocoa.
• OpenGL.
• Carbon. (Ideally you shouldn't need this, but there is some reference to ShowMenuBar and HideMenuBar, which doesn't appear when you build Allegro as a framework.)
• Add the following libraries from /usr/local/lib :
• liballeg.4.4.dylib
• liballeggl.a
• liballeg-main.a  (This is a stub for "main" that glues Cocoa to Allegro.)
• Build the target and it should compile and link.
• You are now good to go at writing OpenGL games using Allegro.

[8-Apr-10] Changed because building as framework just doesn't work properly.

Clanlib vs Allegro vs SDL on Mac OSX

I want to write a little game in C++. Previously, on Windows, I've used Clanlib. This is nicely designed and has pretty much all you need for a game. However, I now have a Macbook (OSX 10.6.2) and Clanlib has fallen behind the times Mac-wise as it still uses Carbon. There don't seem to be any plans to port it and I don't have the experience or time to this work. So I had a look round at the alternatives (again!).

Clanlib 2.1

• Pretty mature, modern library with some nice features (e.g. slots and GUI support).
• Hardware acceleration through OpenGL or DirectX depending on platform.
• Windows and Linux are well supported but Mac has fallen behind, no Cocoa support.
• Version 2.0 was the previous 0.9 version; and 1.0 is the old 0.8 version, renamed. Version 1.0 compiles for the Mac but uses the 32-bit Carbon API. In Xcode 3.2.1 you can no longer create a Carbon project, it must be Cocoa; and if you want to do iPhone, this must definitely be the case.
• Xcode project files provided for Mac. Version 2 needs work.
• Licence: BSD.

SDL 1.2 / 1.3

• SDL is a well thought out low level library, but SDL libraries a bit scattered and some look unmaintained.
• Very portable and core well supported.
• OpenGL compatible.
• Uses Cocoa on Mac.
• Can be built as a framework. 
• Basic sprites don't support rotation.
• Licence for version 1.2:  LGPL.
• Licence for version 1.3: Dual licence, LGPL and commercial (closed source). On embedded platforms (e.g. iPhone) you have no choice but to buy a commercial licence or you are forced to go open source.

Allegro 4.4

• This is quite an old game library but seems to be well supported. Some of it is quite archaic, with palette support and support for old DOS compilers.
• Mac port uses Cocoa.
• API being reworked in Allegro 5.
• Can be built as a framework.
• Uses cmake to generate project files.
• Polling API.
• Minimal external dependencies (e.g. includes JPEG decoder).
• Licence: Giftware.

Allegro 5.1

• Allegro 5 been a long time in development, but worth the wait. Allegro had a lot of cruft from DOS and pre-graphic cards. The latest version is 5.1.
• The API is a lot more organised than 4.x. It is simple and elegant.
• The live version, straight from git (with build instructions) is available. Please note that whilst this contains new features and fixes, it also sometimes contains bugs (which happens during development). If you aren't comfortable with this use the latest stable release.
• OpenGL and DirectX renderers (hardware accelerated) by default.
• Event based API (i.e. not polling).
• Notes on building for Mac OSX.
• Licence: Giftware.
• (This was version 4.9 in the original comparison, which was a work-in-progress version of Allegro 5.0.)

Conclusion

I like the extra features that Clanlib and Allegro supply in their default libraries. Clanlib unfortunately uses Carbon on the Mac and Mac version not supported for long time. This is a real shame because Clanlib includes everything you need (including a GUI).

SDL provides extra features in libraries which I find a little scattered and iPhone development requires a commercial licence if you don't want to release your source code.

So as a result I decided on switching to Allegro 4.4, because unsure how mature 4.9 is, and generally Mac lags behind the main development platforms (Linux and Windows). I'll build my own API, hiding some of the the archaic nature of Allegro. I also decided on Allegro because I found the retro games site, which uses AllegroGL. :-)

I've now switched to Allegro 5. It is still a nice simple API, much improved and tidied up, and libraries updated for modern hardware. Works fine for OSX 10.6.  This is the best, simple cross platform (Windows, Linux, OSX) solution I have found.

[24-Jul-10] Updated because SDL 1.3 has now move to dual licence.
[25-Mar-11] Updated for Allegro 5.0. Removed notes on 4.9 as not useful.
[16-Jan-13] Updated notes on Allegro 5.1.

Banana head

I think we've all had days like this...

Building pygame on OSX Snow Leopard

The version of pygame available on the pygame site works for the python.org version of Python. I want one for the system Python (2.6.1 64-bit). I decided to revisit this after giving up (very easily) the first time.

• First, get pygame source. I'm trying with 1.9.1 release. This sounds like recipe now.
• Untar the source and python config.py reveals some dependencies are necessary. Config will show you which ones you have available.
• The pygame dependencies are as follows. So we'll need collect these. Notes follow.
• SDL.
• SDL_ttf  (fonts).
• SDL_image.
• SDL_mixer.
• smpeg.
• PNG.
• JPEG.
• SCRAP  (cross-platform clipboard).
• PortMIDI.

SDL

• There is a Mac SDL 1.2 package on the downloads page.
• I got SDL-1.2.14.dmg.
• Version 1.2.14 has Snow Leopard support according to the ReadMe.txt and is the minimum requirement. See notes below from UniversalBinaryNotes file:

64-bit Universal Binary Notes:

SDL 1.2.14 is our first release with Snow Leopard on the market. In order to make SDL compile and run in 64-bit, we had to remove code that depended on deprecated Mac APIs and move over to more modern Mac APIs.

In addition, Apple has stopped shipping gcc 3.3 and the 10.3 SDK.

Because of all these combined factors, we have made the decision to make Mac OS X 10.4 the new minimum requirement for SDL.

Our official SDL.framework is compiled as a 3-way Universal Binary (64-bit Intel, 32-bit Intel, 32-bit PowerPC.)

Certain APIs that SDL relies on were not made 64-bit ready by Apple until 10.6. This means even though 10.5 had preliminary 64-bit support, SDL will not compile or run correctly in 64-bit mode on 10.5. So there are two fallout items from this.

First, you can only compile 64-bit code on Snow Leopard or greater (which removes the possibility of 64-bit PowerPC). 

Second, this presents a corner-case where if you have a 64-bit Intel executable in your Universal binary and try to run on 10.5 on an 64-bit Intel Mac, it will launch and crash. To force 10.5 to use the 32-bit version instead of the 64-bit, you should set the LaunchServices key, LSMinimumSystemVersionByArchitecture, in your application's Info.plist. Our SDL/Xcode templates for Snow Leopard already set this up for you.

One additional fallout item is we had to remove the SDL Custom Cocoa Xcode template project. It depended on NSQuickTimeView which was deprecated and removed from the SDL codebase. It may still be possible to recreate the behavior that this template demonstrated, but we would need a volunteer to investigate this.

In addition, the SDL satellite projects were affected by the 64-bit transition.

- SDL_mixer depended on legacy Quicktime for midi playback support. We had to disable midi. (Recall that we also disabled MP3 support awhile back because we never got SMPEG working during the Tiger/Intel transition.) To fix this, we would need a native Core Audio backend for SDL_mixer.

- Since we have changed the baseline to 10.4, we took this opportunity to switch SDL_image over to a new native ImageIO based backend. This makes the binary about 10x smaller, greatly simplifies our maintenance requirements and build process as we no longer have to maintain build systems for 3rd party dependencies, and gives us access to more image formats.

- The static library target for SDL_ttf no longer works because we no longer have access to a libfreetype.a. We have been relying on Apple's supplied libfreetype.a, but they stopped shipping a static version starting in 10.5 which means we have no static 64-bit version. But since 10.4 is our new baseline, all these systems should have libfreetype.dylib installed, so it shouldn't be much of a problem to use SDL_ttf as a dynamic library which dynamically links to libfreetype.

-Eric Wing 2009-09-23

• To install SDL 1.2.14 we copy the SDL.framework to /Library/Frameworks:
• sudo cp -r /Volumes/SDL/SDL.framework/ /Library/Frameworks/SDL.framework

SDL_ttf

• There is a Mac OSX package on ttf project page.
• I got version 2.0.9.
• sudo cp -r /Volumes/SDL_ttf/SDL_ttf.framework/ /Library/Frameworks/SDL_ttf.framework

SDL_image

• Get package from image project page.
• I got version 1.2.10.
• sudo cp -r /Volumes/SDL_image/SDL_image.framework/ /Library/Frameworks/SDL_image.framework

SDL_mixer

• Get package from mixer project page.
• I got version 1.2.11.
• sudo cp -r /Volumes/SDL_mixer/SDL_mixer.framework/ /Library/Frameworks/SDL_mixer.framework

smpeg

• From icculus page.
• svn co svn://svn.icculus.org/smpeg/trunk smpeg
• We'll skip this for, it's optional.

PNG

• Get libPNG from the Sourceforge project download page. I got 1.2.42.
• Don't run configure. Instead: cp scripts/makefile.darwin Makefile
• make
• sudo make install

JPEG

• Source files available at Independent JPEG Group site. 
• I got v8 source (10 Jan 2010).
• ./configure
• make
• sudo make install

PortMIDI

• Source is hosted on Sourceforge. 
• I got version 2.00. Fairly new. 
• Note: PortMIDI uses cmake to generate makefiles. So you'll need to have that installed. I have version 2.8.0. 
• make -f pm_mac/Makefile.osx 
• cd Release 
• sudo make install 

SCRAP

I think this is support for the clipboard for pygame. We are missing sdl-config from our SDL framework install so we can't configure SCRAP to build it. We'll skip this.

Building pygame

So after all that palaver, you can now go to the pygame source and run the config.py.

One problem: Portmidi seems to have changed the name of its static library. It now has "_s" appended. config_darwin.py needs editing:

config_darwin.py:    Dependency('PORTMIDI', 'portmidi.h', 'libportmidi_s', ['portmidi']),

Now:

• python config.py
• python setup.py build
• sudo python setup.py install

After testing... some of the examples work, but fonts don't. :(  This is something to do with SDL linking with a new dynamic library version of freetype which I think is in the /usr/X11/lib direcotory, but this isn't in the dlopen path... Grrr.

Python Game Lab

The Concept

I started a new project on Google Code called pygamelab. Often, when you have some spare time and want to try out an idea it takes you most of the time to figure out which libraries to use, how to use them, debug them and develop your idea. Sometimes, your enthusiasm for the idea has evaporated by the time you finally have the tools to attack it.

It would be nice to have a starting point that was:

• Python: quick and fun to write.
• Portable: Works on Windows, Mac and Linux.
• Has lots of features to play with.
• Has plenty of examples.
• Has some useful tools.
• Well documented libraries.

One popular solution is pygame, but unfortunately Mac support isn't great. You need to install the python.org version of Python in order to install the version supplied off the site; I don't want to do this. I don't want the clutter and confusion. And if you do compile it natively, only other users that have done that can play your games.

The Libraries

So I looked around and found pyglet. This is a portable, Python OpenGL wrapper. It uses ctypes to access the necessary binary libraries for each platform. Pyglet also includes avbin, which gives access to multimedia functionality, like video streaming. Brilliant!

Additionally, there is Cocos2d, a layer on top of Pyglet, which supplies things like game flow, sprite management and tiling. Then for physics, I've chosen pymunk. This uses Chipmunk, the C library, which I've used before. Again, this uses ctypes, but this time to a supplied binary. It works on Windows, Linux and I've supplied a Mac binary (that works with the system Python). There will be more libraries to come as new features get added. I'm currently experimenting with GUI libraries kytten and simplui.

An important point to note is that the libraries are included in the repository. This means a user does not have to install extra Python packages and the versions will be compatible. It also means that I can fix bugs (which has happened) and modify the libraries. For example, they can be patched from the library repo with the latest features. For the package to be portable this means that care should be taken about any binaries that are included. Only two libraries contain binaries at present:

• pyglet, with avbin. This looks to have good cross platform support, and uses ffmpeg, which again is well supported, portable and stable.
• pymunk, which uses Chipmunk. This also looks to have good cross platform support (and 32/64bit support).

Hosting and Version Control

My previous projects have been on SourceForge. This is great site, but it is becoming a little slow and cluttered now. I thought I'd try Google Code, and so far it has been very good. Very fast, nice set of features and not complicated. Just the right level of functionality for managing a small project.

For version control I decided on Mercurial. I'm relatively new to DVCS, but I've really started to like the idea of having a repository that you can clone and experiment with, and also that you don't have to be network attached to commit work. It makes working and experimentation a lot more flexible. It's nice to be able to clone a repo and experiment, commit to that depot, but then throw that work away if you want to. In non-DVCSs you'd have to obliterate the information somehow, and this sometimes has dire consequences.

The other nice feature of Google Code projects is that users can clone a Mercurial repos for their own use. So if you want to collaborate with people, you don't have to give them access to the main repo. They can go away and experiment and do whatever you want, and you can choose whether you want to pull and merge. This is one of the ideas behind pygamelab, that you can clone a useful starting point and do your experiment quickly.

The Future

It's relatively early days, but I'm pretty happy with how it's going so far. I'm planning to supply a few simple default games from different genres that supply lots of different features. These will act as starting points and as sample code. And developing them in the first place is fun besides.

So the idea is:

• You clone pygamelab.
• Mess around.
• If you cloned the repo in the pygamelab project you push back any cool changes.
• Everyone else can see your work and potentially pull it.
• Any good features make it back permanently into the main repo.

Assets

Some of the default assets are from the Lost Garden site. There are some interesting articles on there and I get itching to try them out, but there is always that hurdle of getting started. So hopefully soon I'll be knocking out games or other apps. Just doing the research and getting things going has opened up a whole load of ideas.

Building PyQt4 on Snow Leopard

Here are some notes on building PyQt4 on OSX 10.6 as I always seem to miss a step every time I do this! It should be very similar for all POSIX systems except for a few flags here and there.

My set up: Intel MacBook Pro, OSX 10.6.2, Python 2.6.1 (Apple system python 64-bit, not python.org 32-bit Python).

Get Qt LGPL package. Note, you want the Qt Cocoa libraries as PyQt4 expects 64 bit libraries. The default libraries in the Qt SDK are for Carbon (32-bit) for backwards compatibility. Snow Leopard gcc compiles 64-bit code by default.

• Look here: http://qt.nokia.com/downloads/mac-os-cpp
• Download and install Cocoa 32 & 64 bit libraries.
• Notes on Qt blog: http://labs.trolltech.com/blogs/2009/08/31/qt-46-on-mac-os-106/
• Qt Snow Leopard development notes: http://doc.trolltech.com/4.6-snapshot/developing-on-mac.html

Get latest sip. Build and install:

• python configure.py
• Check configuration is what you want.
• make
• sudo make install

Get QScintilla package from Riverbank.

• cd Qt4
• qmake -spec macx-g++ qscintilla.pro
• make
• sudo make install
• make clean

Now get Mac PyQt4 from Riverbank:

• python configure.py
• Accept the GPL license.
• Check the configuration log doesn't contain anything silly.
• make
• Go and make a cup of tea. You have plenty of time.
• sudo make install
• Test to see if there: python -c 'import PyQt4; print PyQt4'

If you get some error about PyQt4 being 64-bit and Qt is 32 bit, you've installed (or built) the default Carbon version of Qt. Build or install the 64 bit Cocoa version, as instructed above.

Now, back to QScintilla package as we're going to build the Python bindings. This has to be done after PyQt has been built and installed.

• cd Python
• python configure.py
• make
• sudo make install
• make clean

Now the Qt Designer QScintilla plug-in:

• cd designer-Qt4
• qmake -spec macx-g++
• make
• sudo make install
• make clean
• Start Designer and make sure the QScintilla plug-in is there.

Microsoft Shopping Channel Slated

Oh dear, can you smell the fear? Watch the video.

It's like the Microsoft Shopping Channel. Has Ballmer really been reduced to this?

Judging by the comments on the BBC site page I think many consumers have seen the light. Microsoft has failed to deliver. They missed the internet, tried to stifle competition, spent too long on luke warm Vista, and now they're worried about losing market share because they've missed the mobile market. People don't want a PC on a slate. They want something fast, responsive, easy. You don't want to "go into PC mode" when you pull your phone or slate out of your pocket.

And I don't think it's even due to Bill Gates leaving. Microsoft just seem to be doing the same thing, but in a less savvy way now. Microsoft want to be everything to everybody, and you just can't do that. Microsoft have the desktop; it's a given, but Apple have exploited their niche very well, and quietly beavered away to create a great operating system which is part of a package that provides great software that is relevant to people today. For the average user, they hardly need to shell out for anything after buying a Mac. You get iPhoto, email manager, a proper web browser (HTML5?), Garageband, Xcode, and not forgetting Time Machine.

Personally, I'm totally sold on the Mac at home at the moment. I didn't want anything Vista on it. It seemed like a sideways move. What does Vista do amazingly better than XP? Ultimately, the thing that sold me on OSX was Time Machine. I went from one shop looking at Sony laptops with Vista on and then into the Apple store. There was picture on the wall of Time Machine and I suddenly realised that Macs aren't more expensive, and even if they are, they are worth it. You save time and have a more enjoyable user experience. To have fully automated backups on a Mac, completely transparently all you need is an external hard drive.

I'll probably be slagging off Apple one day when they become the complacent, greedy, corporate overlords that everyone hates, but for now I can't wait to see what the "iSlate" will offer. Microsoft are clearly rattled.

Spaces and Command Key

I've finally settled on a set up for switching spaces that I'm happy with on my MacBook. I started off using the command key + arrows to move from one space to another. But the problem with that is that it conflicts with editing any text, as command + arrow keys moves to the start end and end of things, which is a big thing to lose.

I've tried control + arrows and option + arrows, but you always lose some functionality. It doesn't seem very well thought out. And why can't you use the "fn" key on a MacBook with the arrows?

So I've given up on command + arrow keys and now I use command + number keys. This works well for the laptop, or for the keyboard I plug in for serious typing. You can't type properly on those new flat ones. Bah!

It's very quick and comfortable once you're used to it, especially if you use command + tab for switching applications

Monkey Man

This guy is amazing, completely fearless! I hope he gets his funding.

Justin Lee Collins sucks

Why is Justin Lee Collins on television? He just blathers on and on and has nothing interesting to say. He's just like some boring, conceited bloke you accidentally bump into in a pub who you can't get away from. Is this country really so short of talent that this is the best we have to offer? At least he's relegated to Channel 5 now. The slow decline.

Excellent, there is a sack Justin Lee Collins petition. There are also other blogs detailing his crapness on his Star Wars programme. And a group on Facebook.

Enough.