Tell them, my song.

As I’ve posted, I’ve recently begun to ‘breed snakes’, meaning that I’m learning Python when I’m in the mood for some private hacking.

My Python and wxPython installations are the default ones that come pre-installed on OS X Leopard. So far, I’ve been avoiding a customized installation.

I’m using the Eclipse/PyDev combo for my editing, and I really, really begin to like it. No offense to anybody else, but Eclipse is one of the three great Java desktop applications that I’ve seen. (The other two are ‘Tribal Trouble’ and ‘Cyberduck’). Eclipse performs very well, and I just like using it. It’s a personal preference – just use whatever you like and prefer and be happy with it. I’m not religious about that stuff. But I also openly say that I’ve yet to see other good Java desktop applications; most of the Java desktop stuff that I’ve come across looks either out of place or is slow or just plainly sucks. But this posting is not about Java.

Coming back to Python. Today, I’ve been toying a bit with wxPython and I wanted to see how easy – or difficult – it is to create a Macintosh application bundle of a wxPython application with py2app.

So I have this mini wxPython source code here that does not much except for drawing an application window – pardon: frame – and showing a Mac-style menu:

   import wx

   class App(wx.App):
      def OnInit(self):
         frame=wx.Frame(parent=None, title='MyTitle')

         frame.menu_bar = wx.MenuBar()
         frame.help_menu = wx.Menu()

         frame.help_menu.Append(wx.ID_ABOUT, "&About MyTitle")
         frame.menu_bar.Append(frame.help_menu, "&Help")

         frame.SetMenuBar(frame.menu_bar)
         frame.Bind(wx.EVT_MENU, self.on_about_request, id=wx.ID_ABOUT)

         frame.Show()
         self.SetTopWindow(frame)
         return True

      def MacOpenFile(self, filename):
         print filename

      def on_about_request(self,event):
         print "About."

   app=App()
   app.MainLoop()

The few lines of Python code above are stored in a file named NNTP.py in my Eclipse project, and the following code is stored in setup.py in the very same project:

   from distutils.core import setup
   import py2app

   setup(
      app=['NNTP.py']
   )

This should be run like so:

   python setup.py py2app

Or, to make your life even simpler, right click on “setup.py” in the Eclipse Navigator, select “Properties”, then “Edit” the “Run/Debug settings” of setup.py, click on “(x)= Arguments” and add “py2app” to the “Program arguments”. “Apply”/”OK” everything. When you now run the script within Eclipse, you won’t see any error messages, but it will actually create the Macintosh application bundle for you. You will find it in the “dist” folder within your project’s structure in the directory that holds your Eclipse workspace.

The good news is that py2app generates a Universal Binary for you, and in my case it runs both on my PowerPC notebook and my Intel Mac Pro.

The bad news are that it is more than 23 Megabytes in size and it does not run on OS X Tiger. The latter does not make me very happy: It makes the deployment of Python application bundles messy at best.

I have also seen this problem before. The Python game Solarwolf, for example, does not run on OS X Leopard; it was built for OS X Tiger (PowerPC) and that is the only version of Mac OS X on which it runs.

This is bad and in my opinion, deployment nightmares like this should have been fixed years ago – on any system and for any development platform. BlitzMax, the so-called game programming language, does a much better job here than Python. Sure, you won’t get a Universal Binary out of the box in BlitzMax (you actually have to compile your app on both an Intel and a PowerPC machine and then have to do some hand work), but at least the application bundle will not only run on one specific version of Mac OS X.

Deploying Python applications is not yet an issue for me, so I’ve got plenty of time to look into this more thoroughly. There probably is a solution, and maybe even a simple one. But I have a mixed first impression nevertheless. On one side, I am quite happy that so far creating an application bundle is relatively simple. On the other side, I am disappointed that a created bundle only seems to work on the OS X version on which it was built.

Well, let’s see what more I will find out when I dive deeper into this.

UPDATE:

The answer is not to use the Python/wxPython/py2app versions that come with Leopard, but the ‘official’ distributions from Python.org and wxPython.org:

1. Download MacPython 2.5.2 from http://www.python.org/ftp/python/2.5.2/python-2.5.2-macosx.dmg and install it.

2. Download wxPython from http://downloads.sourceforge.net/wxpython/wxPython2.8-osx-unicode-2.8.8.1-universal-py2.5.dmg and install it.

3. Download the source tarball version of py2app from http://pypi.python.org/pypi/py2app/0.3.6 and ‘sudo python setup.py’-install it.

4. I also made sure that in Eclipse’s preferences in the PyDev section, the Python interpreter ‘python2.5′ in /Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python is used.

(Note: I intentionally did not use hyperlinks here.)

After that, the bundles created on Leopard also run on Tiger.

Quite frequently, a discussion pops up in the BlitzMax community about a cell phone port of the BlitzMax compiler. As of today, BlitzMax supports four major platforms: Win32, OS X/PowerPC, OS X/x86 and Linux/x86. Most so-called smartphones use the ARM processor architecture, so when we are talking about BlitzMax for mobile phones, we are firstly talking about a BlitzMax compiler for that specific CPU. But secondly, we also need to talk about a target cell phone operating system.

That smartphone market is currently dominated by RIM (Blackberry), Windows Mobile and Symbian OS. Apple also managed to gain a significant share and, probably more importantly, they have generated a lot of hype around their mobile phone during the last year.

Google announced their own cell phone initiative which they named ‘Android’, and it actually is a development framework based upon Java and other Open Source technologies. There still is no Android phone on the market, and it currently looks a bit as if Android is going to remain what we call a ‘paper tiger’ in Germany.

There are also several cell phones that use operating systems based upon the Linux kernel, and naturally, most Linux geeks vote loudly for GNU/Linux as the target platform of choice for BlitzMax for mobile phones. Companies like ABIresearch estimate a number of around 203 million mobile phones that will be using Linux based operating systems in the year 2012. That looks quite impressive, but it does not say whether this will be a unified Linux platform and if all those cell phones will be software compatible to each other.

Unless a unified platform like Android succeeds, except for the kernel there will probably be only little similarity between those Linux-based cell phones. This situation with various incompatible distributions is already a show-stopper for commercial desktop apps for GNU/Linux and one of the many reasons why large software manufacturers like Adobe are not porting their software to GNU/Linux – they don’t know which Linux distribution they should target. I cannot imagine that the situation is or will be any better in the cell phone world.

Currently, not even the various Java ME implementations for mobile phones are compatible to each other. John Carmack, the founder of and mastermind behind id Software, wrote quite nicely about his experience with Java ME: “Write once, run anywhere. Ha. Hahaha.” I think that pretty much says it.

May the future of Linux on cell phones be bright, but today is 2008, and this is about BlitzMax for mobile phones in a near time frame.

This leaves us with a realistic choice between Windows Mobile and OS X iPhone.

Except for the name, how much has Windows Mobile actually in common with Windows XP/Vista? Supposedly not enough to make porting a compiler for Win32 to Windows Mobile an easy task.

OS X iPhone, however, shares not only the very same operating system kernel with OS X Leopard, but also many of its core frameworks. It should be relatively easy to port BlitzMax to this third OS X platform.

Unlike Java or Flash, BlitzMax would not run into the ‘interpreter’ license clause, since it is a pure compiler and does not use interpreter technologies. (Apple for mysterious reasons prohibits the use of interpreter technologies in their SDK EULA.)

Of all brands and manufacturers, only Apple has a standardized distribution channel for third party software that reaches all of their already more than 10 million phone customers through one portal, including billing services. They also have the most sophisticated and available development platform with the richest feature set.

Except for the official Apple SDK, BlitzMax would not even have a competition in that market.

If I were Blitz Research Ltd and had to select a mobile platform, I would bet on OS X iPhone.

PS: ecto has once again swallowed the original posting while publishing, so I had to re-write the entire posting. This hasn’t happend for the first time, and I just ‘love’ it when ecto does this to me.