Vienna: great transportation system, delicious food (either that, or I was always extremely hungry when I ate), huge portions, restaurants open until midnight. Shame I didn't have time to see the city itself.

The N9 is a gorgeous phone; much more so in real life than in pictures.

After some hassle upgrading the Qt SDK (the provided upgrade tool managed to somehow remove the Qt Creator IDE while purporting to upgrade it; I had to reinstall the entire SDK) and flashing my N950 with Beta 2 firmware (Qt SDK 1.1.3 produces apps incompatible with the old Beta 1 firmware of the N950) I started prototyping a time tracking application in QML, while learning QML and the N9 design guidelines at the same time.

Converting the pretty pictures into QML was harder than I expected, but at the end of the second day I had something that looked like a native N9 application.

Most useful reference pages were:

• The QML syntax introduction (which felt incomplete, but was almost adequate in the end).
• The list of Harmattan-specific QML components.
• The list of standard QML components.
• The UI building blocks pages mentioned above (pretty pictures! pretty colours! I like shiny things!).
• Harmattan Qt Components User Interface Guidelines: pixel and font sizes of the standard UI elements. (Ignore the "import UIConstants.js" red herrings; it's an internal thing apparently, and you can't use it directly from your 3rd-party apps. Unless you find and copy UIConstants.js into your project, after figuring out if the licence allows it, which seemed too much of a hassle for me to even start. So I hardcoded all the numbers directly, like a bad programmer who doesn't know about constants.)
• The TutorialApplication sample, finding the sources of which was unexpectedly difficult -- a straight git clone of the qt-components repository gives you something too recent to run with the older qt-components version on the N9. I ended up using apt-get source qt-components in Scratchbox to download the source tarball of version 1.0~git20110525-1+0m6. Look in qt-components/examples/meego/.

Finally, workflow. QML is parsed at run time (application startup time, unless you delay the loading), which means no recompilation ought to be required to make changes, which means short development feedback cycles ought to be possible. So I was not happy about having to wait several seconds after hitting Run in Qt Creator, while it built a .deb, copied it to the device over wifi or USB networking, installed and ran it there. Deploying to the Qt Simulator is quicker, but not as much as I think it ought to be. Plus, the Qt Simulator apparently cannot simulate the landscape mode of the N9, and it lies about the default font size of QML Text elements (if you do not specify a pixelSize, text elements will look all right in the simulator, but ridiculously tiny on the N9).

In the end I cobbled up a shell script that rsyncs my updated QML files to the device and runs a short Python script (over ssh) to launch them. You need rsync and PySide installed on the device for this, obviously, as well as having SSH set up for passwordless logins. As a bonus, I can now do QML development during lunch, directly on the device, with vim, enjoying proper syntax highlighting. :)

Oh, and my code is up on Github.

6 2

Vienna: great transportation system, delicious food (either that, or I was always extremely hungry when I ate), huge portions, restaurants open until midnight. Shame I didn't have time to see the city itself.

The N9 is a gorgeous phone; much more so in real life than in pictures.

After some hassle upgrading the Qt SDK (the provided upgrade tool managed to somehow remove the Qt Creator IDE while purporting to upgrade it; I had to reinstall the entire SDK) and flashing my N950 with Beta 2 firmware (Qt SDK 1.1.3 produces apps incompatible with the old Beta 1 firmware of the N950) I started prototyping a time tracking application in QML, while learning QML and the N9 design guidelines at the same time.

Converting the pretty pictures into QML was harder than I expected, but at the end of the second day I had something that looked like a native N9 application.

Most useful reference pages were:

• The QML syntax introduction (which felt incomplete, but was almost adequate in the end).
• The list of Harmattan-specific QML components.
• The list of standard QML components.
• The UI building blocks pages mentioned above (pretty pictures! pretty colours! I like shiny things!).
• Harmattan Qt Components User Interface Guidelines: pixel and font sizes of the standard UI elements. (Ignore the "import UIConstants.js" red herrings; it's an internal thing apparently, and you can't use it directly from your 3rd-party apps. Unless you find and copy UIConstants.js into your project, after figuring out if the licence allows it, which seemed too much of a hassle for me to even start. So I hardcoded all the numbers directly, like a bad programmer who doesn't know about constants.)
• The TutorialApplication sample, finding the sources of which was unexpectedly difficult -- a straight git clone of the qt-components repository gives you something too recent to run with the older qt-components version on the N9. I ended up using apt-get source qt-components in Scratchbox to download the source tarball of version 1.0~git20110525-1+0m6. Look in qt-components/examples/meego/.

Finally, workflow. QML is parsed at run time (application startup time, unless you delay the loading), which means no recompilation ought to be required to make changes, which means short development feedback cycles ought to be possible. So I was not happy about having to wait several seconds after hitting Run in Qt Creator, while it built a .deb, copied it to the device over wifi or USB networking, installed and ran it there. Deploying to the Qt Simulator is quicker, but not as much as I think it ought to be. Plus, the Qt Simulator apparently cannot simulate the landscape mode of the N9, and it lies about the default font size of QML Text elements (if you do not specify a pixelSize, text elements will look all right in the simulator, but ridiculously tiny on the N9).

In the end I cobbled up a shell script that rsyncs my updated QML files to the device and runs a short Python script (over ssh) to launch them. You need rsync and PySide installed on the device for this, obviously, as well as having SSH set up for passwordless logins. As a bonus, I can now do QML development during lunch, directly on the device, with vim, enjoying proper syntax highlighting. :)

Oh, and my code is up on Github.

0 0

I started with the Ubuntu packages for FBReader, since they used a more sane build system for .debs (compared to upstream's funky shell script). Some tweaks were needed to make it build in Scratchbox: since GTK+ and Hildon libraries aren't available on Harmattan, I had to disable the building of -gtk and -maemo versions of libzlui. I also got to learn a new tool — quilt.

Fixing the segfault took a couple of days of debugging, studying the source code of both FBReader and Qt itself, and asking for help on IRC. Turns out FBReader was holding an active QPainter instance for too long, and its backing pixmap got destroyed (or, rather, converted from an OpenGL texture to a plain X11 pixmap) during a task switch, causing the crash. I'm probably describing this wrong BTW, but, in any case, adding QPainter::begin() and QPainter::end() calls in the paintEvent handler fixed the segfault.

Next, a small tweak in the .desktop file to make FBReader a single-instance application: change Exec=FBReader to Exec=single-instance /usr/bin/FBReader (I'm paraphrasing slightly).

Then, a more ambitious goal: making FBReader intercept volume keys and use them for scrolling. Google gave me a pointer to QmKeys, which was the wrong API to use here, but gave me a lead to qmkeyd2, which appears to be an open source daemon, which gave me a lead to sysuid, another open source daemon, which in turn gave me a lead to libresourceqt, and that was the right API at last.

Volume keys generate regular key events for XF86AudioRaiseVolume and XF86AudioLowerVolume, but they're also intercepted by qmkeyd2, which tells all subscribers (and sysuid is one) about them. Which subscriber gets to react is determined by the resource policy framework. So what I needed to do in FBReader was acquire the ScaleButtonResource when FBReader starts up or gets focus, and release it when FBReader quits or goes into background. That also required some IRC help until I discovered installEventFilter() and the ApplicationActivate/ApplicationDeactivate events. And QApplication::instance().

The various tools available in the developer firmware were invaluable: openssh, gdb, valgrind, strace, xev, xprop, lsof, netstat. Also, I would not have achieved my second goal without being able to look at the sources of Meego system components (qmkeyd, sysuid). Yay open source!

Here are my changes to the source code. You can find my modified Debian packaging files, as well as prebuilt binary packages (with full debug info, for gdb goodness), in my experimental harmattan apt repository. The UI is still ugly and non-native, but it doesn't matter much in fullscreen mode :) .

Note to self: when next building fbreader, make sure the 2 megabyte tags file doesn't end up in the .diff.gz. And speaking of crud in source packages, the vim package I built for Harmattan the other day contains the entire 50 meg .hg in the .orig.tar.gz. I need to figure out how to tell dh_make to omit it.

4 1

I started with the Ubuntu packages for FBReader, since they used a more sane build system for .debs (compared to upstream's funky shell script). Some tweaks were needed to make it build in Scratchbox: since GTK+ and Hildon libraries aren't available on Harmattan, I had to disable the building of -gtk and -maemo versions of libzlui. I also got to learn a new tool — quilt.

Fixing the segfault took a couple of days of debugging, studying the source code of both FBReader and Qt itself, and asking for help on IRC. Turns out FBReader was holding an active QPainter instance for too long, and its backing pixmap got destroyed (or, rather, converted from an OpenGL texture to a plain X11 pixmap) during a task switch, causing the crash. I'm probably describing this wrong BTW, but, in any case, adding QPainter::begin() and QPainter::end() calls in the paintEvent handler fixed the segfault.

Next, a small tweak in the .desktop file to make FBReader a single-instance application: change Exec=FBReader to Exec=single-instance /usr/bin/FBReader (I'm paraphrasing slightly).

Then, a more ambitious goal: making FBReader intercept volume keys and use them for scrolling. Google gave me a pointer to QmKeys, which was the wrong API to use here, but gave me a lead to qmkeyd2, which appears to be an open source daemon, which gave me a lead to sysuid, another open source daemon, which in turn gave me a lead to libresourceqt, and that was the right API at last.

Volume keys generate regular key events for XF86AudioRaiseVolume and XF86AudioLowerVolume, but they're also intercepted by qmkeyd2, which tells all subscribers (and sysuid is one) about them. Which subscriber gets to react is determined by the resource policy framework. So what I needed to do in FBReader was acquire the ScaleButtonResource when FBReader starts up or gets focus, and release it when FBReader quits or goes into background. That also required some IRC help until I discovered installEventFilter() and the ApplicationActivate/ApplicationDeactivate events. And QApplication::instance().

The various tools available in the developer firmware were invaluable: openssh, gdb, valgrind, strace, xev, xprop, lsof, netstat. Also, I would not have achieved my second goal without being able to look at the sources of Meego system components (qmkeyd, sysuid). Yay open source!

Here are my changes to the source code. You can find my modified Debian packaging files, as well as prebuilt binary packages (with full debug info, for gdb goodness), in my experimental harmattan apt repository. The UI is still ugly and non-native, but it doesn't matter much in fullscreen mode :) .

Note to self: when next building fbreader, make sure the 2 megabyte tags file doesn't end up in the .diff.gz. And speaking of crud in source packages, the vim package I built for Harmattan the other day contains the entire 50 meg .hg in the .orig.tar.gz. I need to figure out how to tell dh_make to omit it.

0 0

I intend to port GTimeLog to it. Although my more immediate need is to have FBReader, so that I can stop carrying both this one and my N900 with me everywhere. Also, vim would be nice.

I've already hacked up Lithuanian support to the virtual and hardware keyboards, thanks to the very nice design of Maliit. As a comparison, I've had my N900 for a year and a half, and I still can't type Lithuanian on it. XKB is not fun.

5 1

I intend to port GTimeLog to it. Although my more immediate need is to have FBReader, so that I can stop carrying both this one and my N900 with me everywhere. Also, vim would be nice.

I've already hacked up Lithuanian support to the virtual and hardware keyboards, thanks to the very nice design of Maliit. As a comparison, I've had my N900 for a year and a half, and I still can't type Lithuanian on it. XKB is not fun.

0 0

Option 1: N900 as a USB modem

Use the provided USB cable to connect the N900 to the laptop. Choose "PC Suite" mode on the N900 when you get the USB connection menu. The laptop now sees your N900 as a bog-standard USB 3G modem. Use Network Manager to connect to the internet.

Pros: no extra setup required. The N900 and the laptop can both access the Internet at the same time.

Cons: you have to use a USB cable (I hate cables). You cannot ssh into your N900 (and ssh is my primary file transfer protocol between the laptop and the M900).

Option 2: N900 as a Bluetooth DUN modem

Install Bluetooth DUN support from Maemo Extras. Then use it like you would any other phone that has Bluetooth DUN.

Pros: no cables.

Cons: Bluetooth is the worst technology ever. I never had it work reliably. Plus, Network Manager in Ubuntu 10.04 doesn't support Bluetooth DUN (it supports only Bluetooth PAN, as far as I know).

Option 3: N900 as a WiFi access point with Joikuspot

I haven't tried this.

Pros: simple (hopefully), no cables required.

Cons: Joikuspot is non-free. I'm not an absolute zealot, but I will avoid closed-source stuff when open-source alternatives are available.

Option 4: N900 as a WiFi access point with Mobilehotspot

I haven't tried this either.

Pros: it's an open-source app available from Maemo Extras. No cables required.

Cons: requires a non-standard kernel (or so I've heard). Way outside my comfort level.

Option 5: N900 as a WiFi access point with shell scripts

Here's the shell script I run on my N900: share-wifi. It sets up an ad-hoc WiFi network, and starts a DHCP and DNS server (dnsmasq). Sadly, it cannot set up connection sharing (NAT), so I rely on OpenSSH as a SOCKS5 proxy. The whole setup is like this:

1. You want the latest firmware (PR 1.2) to avoid this bug.
2. You need to have OpenSSH installed on the N900. Also, setting up key-based authentication makes it more convenient.
3. The script assumes that you've set up sudo on the N900 so that you can run any command as root.
4. You need to have wireless-tools installed. It's in the main SSU repository so you should be able to sudo apt-get install it (if it's not preinstalled; I don't remember).
5. On the N900 run share-wifi in a terminal (optionally passing a WiFi channel number from 1 to 11, in case you need to avoid interference with nearby networks).
6. On the laptop connect to the new n900 WLAN and run ssh -D 1080 user@n900. You will get a shell session; the SOCKS proxy will be active while it is open.
7. Reconfigure your laptop to use a SOCKS5 proxy on localhost:1080. For GNOME systems I've a couple of shell scripts: proxy-on and proxy-off. For applications that do not use the GNOME proxy settings (such as Subversion access over SSH), use tsocks.
8. When done, hit Ctrl-C on the N900 to terminate the sharing script.

Pros: no non-free software or custom kernel required. No cables.

Cons: complicated to set up. No WLAN power savings available for ad-hoc networks, so battery life is extremely poor (~2 hours). But, hey, no cables!

7 0

Option 1: N900 as a USB modem

Use the provided USB cable to connect the N900 to the laptop. Choose "PC Suite" mode on the N900 when you get the USB connection menu. The laptop now sees your N900 as a bog-standard USB 3G modem. Use Network Manager to connect to the internet.

Pros: no extra setup required. The N900 and the laptop can both access the Internet at the same time.

Cons: you have to use a USB cable (I hate cables). You cannot ssh into your N900 (and ssh is my primary file transfer protocol between the laptop and the M900).

Option 2: N900 as a Bluetooth DUN modem

Install Bluetooth DUN support from Maemo Extras. Then use it like you would any other phone that has Bluetooth DUN.

Pros: no cables.

Cons: Bluetooth is the worst technology ever. I never had it work reliably. Plus, Network Manager in Ubuntu 10.04 doesn't support Bluetooth DUN (it supports only Bluetooth PAN, as far as I know).

Option 3: N900 as a WiFi access point with Joikuspot

I haven't tried this.

Pros: simple (hopefully), no cables required.

Cons: Joikuspot is non-free. I'm not an absolute zealot, but I will avoid closed-source stuff when open-source alternatives are available.

Option 4: N900 as a WiFi access point with Mobilehotspot

I haven't tried this either.

Pros: it's an open-source app available from Maemo Extras. No cables required.

Cons: requires a non-standard kernel (or so I've heard). Way outside my comfort level.

Option 5: N900 as a WiFi access point with shell scripts

Here's the shell script I run on my N900: share-wifi. It sets up an ad-hoc WiFi network, and starts a DHCP and DNS server (dnsmasq). Sadly, it cannot set up connection sharing (NAT), so I rely on OpenSSH as a SOCKS5 proxy. The whole setup is like this:

1. You want the latest firmware (PR 1.2) to avoid this bug.
2. You need to have OpenSSH installed on the N900. Also, setting up key-based authentication makes it more convenient.
3. The script assumes that you've set up sudo on the N900 so that you can run any command as root.
4. You need to have wireless-tools installed. It's in the main SSU repository so you should be able to sudo apt-get install it (if it's not preinstalled; I don't remember).
5. On the N900 run share-wifi in a terminal (optionally passing a WiFi channel number from 1 to 11, in case you need to avoid interference with nearby networks).
6. On the laptop connect to the new n900 WLAN and run ssh -D 1080 user@n900. You will get a shell session; the SOCKS proxy will be active while it is open.
7. Reconfigure your laptop to use a SOCKS5 proxy on localhost:1080. For GNOME systems I've a couple of shell scripts: proxy-on and proxy-off. For applications that do not use the GNOME proxy settings (such as Subversion access over SSH), use tsocks.
8. When done, hit Ctrl-C on the N900 to terminate the sharing script.

Pros: no non-free software or custom kernel required. No cables.

Cons: complicated to set up. No WLAN power savings available for ad-hoc networks, so battery life is extremely poor (~2 hours). But, hey, no cables!

0 0

As a penance, here's a Terminal trick for you:

LABELS='[Tab,Esc,Enter,PgUp,PgDn,F2,VKB]'
KEYS='[Tab,Escape,KP_Enter,Page_Up,Page_Down,F2,Return]'
gconftool -s /apps/osso/xterm/key_labels --type list --list-type string "$LABELS"
gconftool -s /apps/osso/xterm/keys --type list --list-type string "$KEYS"

This changes the toolbar to have three extra keys (Enter, F2, and a key that acts like Enter when the hardware keyboard is open, and opens the virtual keyboard if the hardware keyboard is closed).

Update: added screenshot:

Nokia N900 Terminal app with new toolbar buttons

15 0

As a penance, here's a Terminal trick for you:

LABELS='[Tab,Esc,Enter,PgUp,PgDn,F2,VKB]'
KEYS='[Tab,Escape,KP_Enter,Page_Up,Page_Down,F2,Return]'
gconftool -s /apps/osso/xterm/key_labels --type list --list-type string "$LABELS"
gconftool -s /apps/osso/xterm/keys --type list --list-type string "$KEYS"

This changes the toolbar to have three extra keys (Enter, F2, and a key that acts like Enter when the hardware keyboard is open, and opens the virtual keyboard if the hardware keyboard is closed).

Update: added screenshot:

Nokia N900 Terminal app with new toolbar buttons

0 0

In other news, my Nokia N810 Internet Tablet finally arrived. It looks better in real life than in pictures.

Strange quirk: the 2 gigs of extra internal flash memory (formatted as FAT32) are mostly unused (according to df) while at the same time being three quarters full (according to du):

/media/mmc2 $ df -h .
Filesystem                Size      Used Available Use% Mounted on
/dev/mmcblk0p1            1.9G      8.0k      1.9G   0% /media/mmc2
/media/mmc2 $ du -sh .
1.5G    .

Ouch. Time to run fsck.vfat on it. Or perhaps just reformat, to avoid the other famous bug (attempt to access beyond end of device), which, let me check, yes, I also see:

[584959.868000] usb-storage: device scan complete
[584959.868000] scsi 3:0:0:0: Direct-Access     Nokia    N810              031 PQ: 0 ANSI: 2
[584959.868000] scsi 3:0:0:1: Direct-Access     Nokia    N810              031 PQ: 0 ANSI: 2
[584959.872000] sd 3:0:0:0: [sdb] 3932160 512-byte hardware sectors (2013 MB)
[584959.872000] sd 3:0:0:0: [sdb] Write Protect is off
[584959.872000] sd 3:0:0:0: [sdb] Mode Sense: 0f 00 00 00
[584959.872000] sd 3:0:0:0: [sdb] Assuming drive cache: write through
[584959.872000] sd 3:0:0:0: [sdb] 3932160 512-byte hardware sectors (2013 MB)
[584959.876000] sd 3:0:0:0: [sdb] Write Protect is off
[584959.876000] sd 3:0:0:0: [sdb] Mode Sense: 0f 00 00 00
[584959.876000] sd 3:0:0:0: [sdb] Assuming drive cache: write through
[584959.876000]  sdb: sdb1
[584959.880000]  sdb: p1 exceeds device capacity
[584959.884000] sd 3:0:0:0: [sdb] Attached SCSI removable disk
[584959.884000] sd 3:0:0:0: Attached scsi generic sg2 type 0
[584959.884000] sd 3:0:0:1: [sdc] Attached SCSI removable disk
[584959.884000] sd 3:0:0:1: Attached scsi generic sg3 type 0
[584960.240000] attempt to access beyond end of device
[584960.240000] sdb: rw=0, want=4013848, limit=3932160
[584960.240000] Buffer I/O error on device sdb1, logical block 501728

It would be interesting to know how this came to be. Do some N810s have more internal memory than others? Or was the filesystem image made too big for all of them by accident?

4 2

python -m zipfile -e filename.zip .

6 1

Today I hacked up this feature for FBReader. Get the .deb in the usual place.

FBReader with Table of Contents marks in the position indicator. The book is An Oblique Approach by David Drake and Eric Flint, from the Baen Free Library.

While I was doing that, bzr decided to shake my confidence in it and started throwing assertion errors right and left (no link, the mailing list archive lags horribly).

0 6

Changes I like best: extra RAM, speed, storage space. The built-in stand. Position of the headphone and charget sockets. Screen (shinier, not as grainy, although I think it reflects a bit more ambient light than the 770 used to). The ability to reorder status bar icons. New Opera toolbar. Backup application that works without killing all other applications and entering offline mode. New themes. Battery time estimates.

Changes I'm not sure I like: new stylus (too short). Lack of hard case (without it I'm forced to lock the keys when I stuff it into my pocket, but the tiny power button is hard to press). The new shape (it's harder to hold it in my right hand while pressing the down button, which is how I like to read books sometimes). The tearing effects when panning in Opera.

The new Media Player merits a category on its own. It indexes all the media files (songs and videos) in ~/MyDocs and in all memory cards automatically. That's very nice when it works. It's frustrating when it doesn't. There's no way to force reindexing after you shuffle files around manually, and no indication when the automatic reindexing is finished. You just have to wait and hope that it will catch up. Also, sometimes the user interaction is very strange: bug 1056, bug 1063.

Overall, I like it better than the 770.

2 5

As a result I have more free time for hacking. Today I tried to play around with Metacity's compositor, with some mixed success. I also built a patched FBReader with a numeric page indicator tweaked to the size and position of my liking (screenshot). Bzr rocks for maintaining branches!

eazysvn also got a facelift today. It is now installable with easy_install.

<rant>
I do not like easy_install. It wants to install stuff into /usr/lib/python2.4/site-packages. That location is reserved for Debian packages. A sensible default would be /usr/local/lib/python2.4/site-packages or, preferably, somewhere in my home directory, with the caveat that I'll have to set up PYTHONPATH myself. You can force easy_install to do more or less what you want, but that involves reading tons of documentation, invoking arcane multi-thousand line scripts, or sacrificing small animals. Not my definition of "easy".
</rant>

Last night I submitted a patch to add a tiny help topic to bzr. Before that, nights were dedicated to zope.testing and pyspacwar.

In the mean time, actual paying work suffers. Karmic retribution for those three 11-and-a-half hour days I spent at work during the first week of January? No, just lack of willpower to force myself to go to sleep (or wake up) early instead of, for example, blogging.

0 5

During nights I worked on PySpaceWar: added sound effects, support for background music (but didn't look for freely redistributable soundtracks yet), some visual effects, some more configuration options. And once again playing the game became more interesting than coding it. I can beat the computer with 100 kills to its 50-60. I should release a new version soon.

Today I discovered the cause of a long-standing problem of random reboots of my Nokia 770. Turns out FBReader leaks file descriptors, and once the system runs out, some important process crashes and the device reboots. A patch and a fixed .deb are on my FBReader page (of course I also sent the patch upstream).

Meanwhile Nokia released the N800. *drool*. Twice as much RAM, twice as much "disk" space (flash memory, actually), faster CPU, two full-size SD slots, interesting software updates. I want one, but since Nokia only sells them in a few countries, I'll probably have to wait until somebody I know can bring one to me.

0 6

Five days later I discover that it doesn't work any more. Actually, it works, but the battery is dead. I left the battery connected to the voltage regulator, and that was enough to drain it.

Wikipedia says that carbon-zinc 9V batteries have a typical capacity of 400 mAh. ThoughtFix measured the circuit power readings at 4.62 mA with both USB ports disconnected. That's enough to drain a 400 mAh battery in 86 hours or 3.6 days. And here I thought it would last for months...

Time to buy a new battery. And this time I'll keep it disconnected when I'm not using it.

0 6

Nokia surprised everyone on the first day by handing out 300 pre-release N900s to the participants. I'm so happy now that after a long period of wavering I finally decided to come to the summit! The device is much better than I expected/feared (and I haven't even put a SIM card in yet). We're supposed to provide feedback and will have to send the devices back to Nokia in 6 months. (Nokia insisted on loan contracts signed in blood, kidding, but there are contracts.)

The tiny pixels are beautiful. It's what, 266 pixels per inch? Even older 225 dpi devices spoiled me: both the first generation iPhone and the first generation Kindle displays seemed very coarse and pixellated.

The user interface is very smooth. Having a composition manager improves apparent responsiveness: even if the app is swapped out and not ready to redraw, switching between windows appears to be instant since the picture is cached. And there's no flicker while the apps are redrawing. (Flickering during redraw is one of the main reasons I did not buy a S60 phone and stayed with good old S40.) Speaking of swapping, it's barely noticeable. You can run more apps than fit in RAM without having to suffer. The flash memory is noticeably faster than in a N810. And there's more of it (32 gigs: 28 gig partition for user data, the rest for the system: swap, applications, config files, etc.)

The design and usability of the user interface have improved a lot since the N810. The UI is pretty. Many of the apps are now convenient to use. Pervasive kinetic scrolling is sweet (except when you have really long lists or web pages, then it takes forever to reach the end).

Finally there are PIM-y things people missed in older Maemo releases: calendaring, contacts that can record all kinds of information (such as phone numbers).

All right, enough gushing. There were some irritating things too. For example, Bluetooth support is buggy/incomplete in the pre-release firmware, so it's hard to transfer files. Calendar/contacts sync with S40 phones does not work either. GPS is utterly useless when you're offline (no maps, or at least I haven't found a way to pre-download and cache them; also very long fix times without network assistance). Since I have no desire to pay extortionist roaming charges of my provider (2.5 EUR per megabyte), and haven't had a chance to go look for a prepaid SIM card, I usually have either WiFi or GPS coverage, but not both.

As you can guess, playing the device diverted a part of my attention from the presentations somewhat. I tried to compensate for that by reporting on the talks on IRC (using xchat on the device). I think the strategy backfired; IRC is rather disruptive and the channel is quite busy lately.

16 0

Nokia surprised everyone on the first day by handing out 300 pre-release N900s to the participants. I'm so happy now that after a long period of wavering I finally decided to come to the summit! The device is much better than I expected/feared (and I haven't even put a SIM card in yet). We're supposed to provide feedback and will have to send the devices back to Nokia in 6 months. (Nokia insisted on loan contracts signed in blood, kidding, but there are contracts.)

The tiny pixels are beautiful. It's what, 266 pixels per inch? Even older 225 dpi devices spoiled me: both the first generation iPhone and the first generation Kindle displays seemed very coarse and pixellated.

The user interface is very smooth. Having a composition manager improves apparent responsiveness: even if the app is swapped out and not ready to redraw, switching between windows appears to be instant since the picture is cached. And there's no flicker while the apps are redrawing. (Flickering during redraw is one of the main reasons I did not buy a S60 phone and stayed with good old S40.) Speaking of swapping, it's barely noticeable. You can run more apps than fit in RAM without having to suffer. The flash memory is noticeably faster than in a N810. And there's more of it (32 gigs: 28 gig partition for user data, the rest for the system: swap, applications, config files, etc.)

The design and usability of the user interface have improved a lot since the N810. The UI is pretty. Many of the apps are now convenient to use. Pervasive kinetic scrolling is sweet (except when you have really long lists or web pages, then it takes forever to reach the end).

Finally there are PIM-y things people missed in older Maemo releases: calendaring, contacts that can record all kinds of information (such as phone numbers).

All right, enough gushing. There were some irritating things too. For example, Bluetooth support is buggy/incomplete in the pre-release firmware, so it's hard to transfer files. Calendar/contacts sync with S40 phones does not work either. GPS is utterly useless when you're offline (no maps, or at least I haven't found a way to pre-download and cache them; also very long fix times without network assistance). Since I have no desire to pay extortionist roaming charges of my provider (2.5 EUR per megabyte), and haven't had a chance to go look for a prepaid SIM card, I usually have either WiFi or GPS coverage, but not both.

As you can guess, playing the device diverted a part of my attention from the presentations somewhat. I tried to compensate for that by reporting on the talks on IRC (using xchat on the device). I think the strategy backfired; IRC is rather disruptive and the channel is quite busy lately.

0 0