Yep, checking the number of lines & changing the font size accordingly should do the trick.

I think this is the default behavior for the Maemo 5 Qt Components port - it tries to fix the lack of Swipe by basically adding invisible Hildon style window controls. So clicking the upper left corner will probably close modRana.

As modRana has no need for these invisible buttons due to the fullscreen toggle button on the map screen, I'll have to check out how to disable them (or change the behaviour so that it won't clash with the back button).

Thats the geographic point, where both latitude & longitude are equal to zero.
I'll change it to the last known position in a future update.

Well, why not. But I've never worked with crash-dumps before, so also a pointer what to use to analyze it would be welcome.

I'll also try to do some stress testing to check if I can also manage to make it segfault. BTW, I've also had quite a few segfaults initially on Fremantle:

• after importing python-mobility - solved by this contraption as found in a bug-report somewhere
• random segfeaults & segfaults when minimized - solved by making sure no GTK/Gobject/Hildon stuff is accidentally loaded when running with the QML interface

GTK & company making Qt application segfault is quite a weird combination, considering that for example the latest AGTL has a QML interface, which is used together with a Gobject based (signals, callbacks) "core".

Yes, it is, but it only supports QtQuick 1.0. CSSU & Harmattan have 1.1. Also, on non-CSSU Qt Components have a different namespace (org.maemo.fremantle vs the usual com.nokia.meego).
As a result, I would need to maintain two versions for all QML files - one for vanilla Fremantle which has the Fremantle QtC namespace & uses only QtQuick 1.0 features (no pinch area, no image caching, some other missing properties, etc.) and then a "normal" version for CSSU & Harmattan.

Due to the missing features in QtQuick 1.0, just replacing the namespace won't do, I would have to to synchronize the changes between the two by hand. And the QML files change a lot - it's just too much work.

Actually, I tried to make a separate non-CSSU QML files for Mieru - but even after changing the namespace & commenting out all the QtQuick 1.1 features, the application started, but with a very broken layout & there were other issues (no support for multiple decorators) caused by the old PySide version. Never got it to work usably on non-CSSU in the end. I have since then upgraded my N900 to CSSU, so I don't have a real device to test the non-CSSU version on anyway.

Yep.

Well, the "classic" GTK interface is still usable without issues on both CSSU and non-CSSU, so old Qt version should not be preventing users from running modRana with the GTK GUI.

But I can (and probably will) add a runtime Qt version detection. If it detects Qt version < 4.7.4 (Harmattan also has 4.7.4, non-CSSU has 4.7.0) it would show a "You need to upgrade to CSSU to run the new QML based modRana interface." instead of just crashing.

Probably the QML interface.
The GTK interface:

• does full screen redraws only
• redraws at least once per second even if nothing changes
• when drawing the map, tiles are laid-out, rotated, scaled, etc. again on every redraw
• runs everything on CPU

Don't really know about how QML handles screen redrawing but I'd guess it should be much more efficient. Also, it either uses some form of GPU acceleration or is just much more optimized, consider how much more smooth it is.

Still, might be interesting to compare the two in some simple battery usage benchmark.

This happens when you press a menu on a button that points to a page menu/screen that is not yet present. Nothing serious.