LeMMA is now open-source

It has been my intention to open source LeMMA for some time already, but I’ve been sitting on it. I’ve finally got around to releasing LeMMA under the GPL. The codes are now at https://github.com/geksiong/LeMMA.

What’s next? I admit I have not been updating LeMMA and have not been keeping up with MMA development. If anyone has ideas how to take LeMMA to the next level, I would like to hear from you.


LeMMA 0.9 alpha

I’ve been sitting on a couple of features for quite a while now. Here they are:

  • Want to play in different key? Now you can transpose chords!
  • Added support for PyGame midi engine. PyGame’s timidity player is a bit outdated, but it’s an alternative to using an external player software.

Also, for python 2.4 users who found that the last version broke for you. This release should fix that problem.

Download the latest version of LeMMA.

LeMMA 0.8 alpha release

LeMMA 0.8 is now available as an alpha version. A more ‘contemporary’ look-and-feel has been adopted for this version. I’ve also added various usability improvements (e.g. keyboard navigation using arrow keys), and some attempts at supporting the Mac platform better. A new .ini-like configuration file format is used, using the built-in Python config file parsing library, replacing the previous Pickled file format.

If there are any Mac python programmers using this, I’m interested in learning what’s the proper way to package a Mac python application, and any other advice you can give me.

Here’s a screenshot of the new GUI:

Get it from the usual place.

I’ve been working on enhancing the user interface of my LeMMA app, which is written in Python/Tkinter. This discusses some of my thoughts while researching the current state of the art with regards to using Tkinter.

Why did I choose Tkinter when there are other widget libraries that looks better and works natively? My decision was mainly based on the ease of installation by users, i.e. no installation required. Because Tkinter comes standard with Python on almost all platforms (except on Ubuntu where you must explicitly install the python-tk package). I don’t want my users to have to install any third-party widget libraries. Users should be able to simply unzip and run the app immediately.

(For the record, I’ve used PyGtk and like it, but I still haven’t found an easy way to install GTK on Windows, other than installing other GTK apps like GIMP or pidgin…)

However, Tkinter suffers from the following issues:

  • Dated look and feel: Surprisingly, despite Python’s widespread use in the major Linux distros, Tkinter looks ugliest on Linux. For Gnome-based distros, it appears that the PyGtk bridge is a more popular choice for GUI Python apps.
  • Lack of good documentation: Yes, there is the Tk documentation, but what is mentioned there is not necessarily available in Python. And some options don’t work for some widgets/platforms. For certain platforms, e.g. Mac you have to resort to direct Tk calls to get certain behavior, and even then not everything described works. You can find some good resources at NMT and effbot.org, but they are not complete. It’s no wonder that we often refer to it as Tk ‘folklore’.

And some platform-specific problems I discovered are:

  • On Linux, the menu in the OptionMenu widget won’t display if it is taller than screen height. The menubutton+menu approach works, but it doesn’t scroll so it is still not useable. Mac and Windows implementations use native menus that can scroll.
  • Mac doesn’t support flat relief buttons (well, I use them in LeMMA, so they looked really bad).
  • Tix is currently broken at least on Ubuntu due to version mismatch in packaging (Ubuntu python is compiled with Tk 8.5, i.e. ttk support). Ok, this is not really a valid problem, but no Tix-love until Ubuntu fixes its repositories. What? You mean there isn’t any Python Tix apps that people are complaining are broken in Ubuntu…?

The next-generation Tkinter is ttk (Tiled Tk), which is able to use native widgets in Mac and Windows, however:

  • It is NOT a drop-in replacement for Tk. Current apps won’t be automagically beautified. You will need to explicitly import the ttk module.
  • It’s not just a simple import statement. Only a subset of widget options are supported in ttk, and the style options were removed. Styling in ttk has a different approach. Perhaps this is a better way, but it means that old Tkinter programs wanting a fresh coat of paint need to be re-coded.
  • Even if a simple import works, all subclassed Tk widgets will NOT get the benefit of ttk, so no third-party widget extensions, or you will get a weird ‘mashup’ of different widget look-and-feel.
  • On the plus side, assuming the documentation at the TkDocs website is accurate, the standard extended widgets will be styled eventually in future Python releases (version 2.7?). That’s not the case yet for the current Tkinter/Tk8.5 implementations as far as I know.
  • Widgets on Linux will look somewhat better, but it’s still ugly, partly because there is no one standard native widget engine, unlike Mac and Windows. Hopefully, at least GTK and Qt can be supported in future, as they are what’s used in most modern Linux distros today. I don’t think the built-in theming support in ttk is the correct way ahead (I’m still looking for instructions on how to design and install new themes for use in Tkinter).

We are finally seeing the beginning of real cross-platform GUI development with Tkinter, using native widgets, but there are still quite a few raw edges. For now I’ll use the following approach:

  • Current: Use the Tk 8.4 widgets set, and write my own pure Tk widgets extensions, avoiding the use of all third-party Tk extensions.
  • Near-future: Re-code my app to auto-detect the availability of ttk and continue to work with and without it. A command-line option to force either selection is also recommended, in case ttk doesn’t work for some users.
  • (Far?) future: When ttk is finally mature, stable and widespread, to Use only ttk widgets.

Another consideration is the eventual migration of your app to Python 3. That might be good time to make a clean break between 2.x + Tk8.4 apps and 3.x + Tk8.5/Ttk apps.

Of course, if you just want to write new Python apps for the future and don’t care about the current installed base, by all means go ahead and write in Python 3 (which is already supported in Python 2.6) and ttk. We need good apps to encourage people to switch anyway. 🙂

Having been using git for some time now, I decided it was time I get comfortable with branching. I was trying to configure a color bash prompt that can tell me which git branch I’m currently in (using “__git_ps1”), with a color indicator to tell me whether the working directory is dirty or not. There are a lot of examples online, but I soon hit a problem – long lines get wrapped on the same line instead of moving to the next line. And trying to backspace reveals an ‘invisible wall’.

The problem is because in order to get the ‘dirty’ color indicator, I called an external command from within the pompt. Now the way to return a string from a bash function is to use echo. This is the catch: color ANSI codes in the output are also counted by bash as part of the prompt when determining when to wrap, and this screws it up.

The Bash Prompt How-To says that non-printing characters (that includes the ANSI color codes) must be delimited with \[ and \]. However,I found that this does not work if echoed from a function. They must be defined in $PS1 directly otherwise bash cannot interpret it.

I could workaround this problem by defining another function to return a color only, in addition to the one for the git branch, but since deciding on the color also means deciding whether we are in a git repository in the first place, this is essentially doing the same thing twice and is not elegant anymore. I decided to settle for printing an asterisk as a dirty flag instead.

I’m not familiar with the history of terminal programs, but I think perhaps it shouldn’t be too hard to get bash to autodetect the ANSI color codes as non-printing characters and not count them into the prompt length? It will still be compatible with the use of \[ and \], and it will save a lot new users a lot of frustration.

Ubuntu 9.04 is out!

I just upgraded to Ubuntu 9.04 on my laptop and netbook. The upgrade experience was quite smooth, but I’m expecting the bugs to start appearing. So far, I’ve found that gnome system monitor is crashing for some reason. I don’t feel very ‘jaunty’ yet.

I also tried installing the real-time kernel on the netbook but it failed to boot. Disappointing, as the real-time kernel has not been working for me since 8.10.

Update 1 May 09: Looks like the major issue with Jaunty is the graphics. EXA is supposed to be a new and better way to do graphics than XAA, but for me the performance is much worse (especially in Flash, which is already bad enough under Linux). On my old Dell D600 (ATI Radeon Mobility 9000) I had to set AccelMethod back to XAA. On my Asus 1000HE (Intel 945GME) setting XAA doesn’t work – I’m still studying the options. The new audio mixer also has some quirks. The only plus side for me is that on the Asus 1000HE touchpad edge scrolling is now enabled, but all in all I think Jaunty is pretty much a flop. No point getting faster boot if the system lags after booting.

After installing Ubuntu on my Asus 1000HE, I decided to repartition the hard disk, so I backed up everything using fsarchiver and restore everything after I was done.

I found that the UUID for the swap partition has changed from the repartitioning so I edited /etc/fstab to mount the new swap partition. Then I discovered that my Ubuntu boot splash refused to stay in graphical mode. It will always drop to text at the “resume image” step. What to do? Google for the solution!

Turns out that this step in the boot process is looking for the swap partition at the old UUID.

There are two ways to fix this:

METHOD 1: Recreate the swap partition with the old UUID. Revert the /etc/fstab entry as well.

METHOD 2: Update /etc/initramfs-tools/conf.d/resume to reflect the new swap UUID, then run ‘sudo update-initramfs -u’ to update the initramfs image.

And voila, graphical boot all the way to the login screen!