Nokia 770 + a random Bluetooth GPS + Maemo Mapper + Google Maps = fun.

Nokia 770 and NaviLock BT-308 GPS

The fun part consisted of

• Patching Maemo Mapper so that it can use Google satellite map pictures.
• Banging my head against the wall trying to understand why Maemo Mapper won't talk to the GPS today, when it worked perfectly yesterday.
• Googling for BT-308 protocol descriptions.
• Discovering that BT-308 speaks two protocols: NMEA-0138 text protocol and SiRF binary protocol.
• Discovering that Maemo Mapper only speaks (well, listens to) NMEA-0138.
• Discovering that gpsdrive/gpsd that I tried yesterday evening (without much success) tell the GPS device to switch to the binary protocol (which is apparently the same that Garmin devices use).
• Discovering that turning the GPS off and back on does not switch the protocol back to NMEA.
• Reading the SiRF binary protocol refeference manual and writing a short Python script to connect to the GPS via Bluetooth and tell it to use NMEA.

Maemo Mapper

I've been playing with my Nokia 770 for a couple of days now.

• SSH server on the 770 rules -- I can now access the filesystem using Midnight Commander's Shell Link, or GNOME VFS. Not to mention looking around in the filesystem, editing .profile with a convenient keyboard, etc.
• The ability to mount NFS shares directly on the 770 rules. I only wish the video player could play any of the random video clips that I try throwing at it. Is anyone planning to port mplayer to the Maemo platform?
• FBReader's full-screen portrait mode is very nice. It could be improved a bit, but it is already great.
• The CPU/MEM applet is absolutely essential. So is the clock applet. (How do you differentiate status bar applets and home page applets? It's confusing to call them both applets.)
• The web browser is quite good.
• After reading ebooks for about 4 hours, the battery is still at 3/4.

Overall impression: the system and applications lack stability, but is quite usable.

Yesterday I received my Nokia 770. First impression: the device has great potential, and is a nice hacker toy (woohoo, Linux!), but it is not ready to replace my PDA (Tungsten T). Palm makes everything it can do more convenient. Of course, my Palm doesn't have 802.11b/g, nor a good web browser...

Essential software: CPU/RAM usage applet, clock applet, FBReader.

Nice to have: XTerm, OpenSSH client, Midnight Commander, VIM (not available right now, waah!), XChat, VNC Server, GWeather.

I also want to install the OpenSSH server, but I need to become root, which is a scary process.

Some observations:

• I cannot figure out how to turn it on, when the charger is not plugged in! Am I stupid, or what? No matter how long I hold down the power button, nothing happens. Even when the charger is plugged in, it takes a few tries until I manage to turn it on.
• The screen has incredible resolution (225 dpi), but white background looks very uneven and grainy. Is this the fault of the protective plastic that covers the LCD?
• It was pretty difficult to figure out how to assemble the clever little stand (documentation? who reads documentation?).
  
• The user interface feels very sluggish.
• It doesn't charge from USB. A pity.
• You cannot use SD/MMC cards with it. Only RS-MMC.
• 64 megs of RAM is not much.
• My Nokia 770 keeps dropping the WiFi connection even in the middle of web browsing. You have to reconnect explicitly, which is a pain.
• Handwriting recognition is not bad, and kind of fun. I could enter text with Graffiti faster, though (because I had to make less corrections).
• Hardware buttons autorepeat, sometimes with too little delay. Even the fullscreen toggle button. It is very easy to accidentally press a button twice.
• There are a lot of little nagging details that are just wrong. Examples: there's no way to launch new applications by using just the hardware buttons, you need to get the stylus. If you zoom in on a PDF so that a horizontal scrollbar appears, there's no easy way to go to the next page with hardware buttons. Most of the menus are too deep, e.g. you have to make 3 clicks for copying or pasting a selection. Dialog windows shrink when the onscreen keyboard appears, but do not grow back when the keyboard disappears. I could rant for hours.

Summary: I do not regret buying it. If the platform (Maemo) weren't open-source, I would be unhappy. Now I know that I can (in theory) fix all the problems myself, and that makes me content

I've been using Linux for almost 10 years now, so I'm used to the command line. Most of the windows in my GNOME desktop are GNOME Terminals. And when you have many of them, you'd like to distinguish them somehow in the window list or window selector applets.

My .bashrc specifies a $PROMPT_COMMAND that sets the username, hostname and the current working directory in the title bar. I can therefore distinguish root terminals and remote terminals (ssh rules), and terminals where I work on different projects in different directories. Until recently I couldn't, however, distinguish the terminal which was running Zope 3 from a terminal which was running functional tests from a terminal which was running an svn update.

For a long time I wanted to see the currently executing command in a terminal title. I always thought this was impossible with bash. David Pashley proved me wrong. I had to change his recipe a little bit, because it interferes with $PROMPT_COMMAND in a nasty way. Here's my .bashrc now:

# If this is an xterm set the title to user@host:dir
case "$TERM" in
xterm*|rxvt*)
    PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}: ${PWD}\007"'

    # Show the currently running command in the terminal title:
    # http://www.davidpashley.com/articles/xterm-titles-with-bash.html
    show_command_in_title_bar()
    {
        case "$BASH_COMMAND" in
            *\033]0*)
                # The command is trying to set the title bar as well;
                # this is most likely the execution of $PROMPT_COMMAND.
                # In any case nested escapes confuse the terminal, so don't
                # output them.
                ;;
            *)
                echo -ne "\033]0;${USER}@${HOSTNAME}: ${BASH_COMMAND}\007"
                ;;
        esac
    }
    trap show_command_in_title_bar DEBUG
    ;;
*)
    ;;
esac

There's an LCD monitor standing on the desk next to my laptop at work. I use MergedFB to get a combined 1024x786+1280x1024 desktop. (Here's my /etc/X11/xorg.conf if anyone with a Radeon card is interested.)

GNOME doesn't fully understand this setup yet (bug #147808). It thinks I have a single large 2304x1024 desktop, and it sets the wallpaper accordingly. I can tile or stretch an image, but I cannot set separate images for each monitor. And tiling doesn't work well with different monitor resolutions.

What I needed was a tool to take two images, scale them appropriately and paste them together into one large 2304x1024 image. Easy! I did some browsing of the Python Imaging Library online documentation and 45 minutes later I had dualpaper.py, a nice command-line script with robust option parsing.

Encouraged by easy success I took on the next challenge: writing a GUI app so that I could drag and drop a couple of images, hit a button, and get a newly constructed wallpaper. This was a bit harder. I used PyGtk and Glade. I spent some frustrating time trying to locate PyGtk examples (to see how drag&drop works) until I finally located them in /usr/share/doc/python2.4-gtk2/examples/demos/. I spent even more time Googling about Xinerama so that I could automatically determine the size of each monitor, until I discovered gtk.gdk.Screen.get_monitor_geometry. The rest was straightforward, and I had a fully functional prototype in less than 2 hours.

That's why I love Python: it enables me to achieve results very quickly. (By the way, how do I know this excercise took 2 hours and 34 minutes? GTimeLog!).

Update: the code now has a webpage.