New website for Mappero Geotagger, and cross-compiling stuff

Alberto Mardegan — Sun, 12 Apr 2020 09:20:55 GMT

Mappero Geotagger has now moved from its previous page from this site to a new, separate website built with the awesome Nikola static website generator.

The main reason for this change is that I didn't have an online space where to host the application binaries, and I wanted to experiment with a different selling method. Now, downloads are (poorly) hidden behind a payment page, whereas in multiple places of the website I also mention that I can provide the application for free to whomever asks for it. While it might seem weird at first, I do honestly believe that this will not stop people from buying it: first of all, many people just think it's fair to pay for a software applications, and secondly, for some people writing an e-mail and establishing a personal contact with a stranger is actually harder than paying a small amount of money. And in all sincerity, the majority of the income I've had so far for Mappero Geotagger came from donations, rather than purchases; so, not much to lose here.

QBS and MXE

Anyway, since this is primarily a technical blog, I want to share my experiences with cross-building from Linux to Windows. As you might remember, some time ago I switched the build system of Mappero from qmake to QBS, and I haven't regretted it at all. I've managed to build the application in Linux (of course), macOS, as a Debian package on the Ubuntu PPA builders, on Windows with AppVeyor and, last but not least, on Linux for Windows using the mingw setup provided by the MXE project.

QBS worked surprisingly well also in this case, though I had to fight with a small bug on the toolchain detection, which is hopefully going to be fixed soon. For the few of you who are interested in achieving something similar, here's the steps I ran to configure QBS for mingw:

    MXE_BASE=<path-to-mxe>
    MXE_TARGET=x86_64-w64-mingw32.shared # 32 bit or static targets are also available

    MXE_PROFILE="mxe"
    QT_PROFILE="${MXE_PROFILE}-qt"
    qbs setup-toolchains "${MXE_BASE}/usr/bin/${MXE_TARGET}-g++" $MXE_PROFILE
    qbs config profiles.$MXE_PROFILE.cpp.toolchainPrefix "${MXE_TARGET}-" # temporary workaround
    qbs setup-qt "$MXE_BASE/usr/$MXE_TARGET/qt5/bin/qmake" ${QT_PROFILE}
    qbs config profiles.${QT_PROFILE}.baseProfile $MXE_PROFILE

Sorry for using that many environment variables ☺. After qbs is configured, it's just a matter of running

    qbs profile:$QT_PROFILE

to build the application. You will get a nice window binary and, once you collect all the needed library dependencies, you'll be able to run it on Windows. Or WINE ☺.

As part of this effort, I also had to build libraw, so I didn't miss the occasion to contribute its recipe to MXE. I'm also trying to get a change accepted, that would make MXE support the dynamic OpenGL selection available since Qt 5.4.

Fixing berserk rotations in Mapper

Alberto Mardegan — Tue, 16 Mar 2010 13:53:00 GMT

Maemo Mapper has a nice feature which is called "automatic rotation" and consists in automatically rotating the map so that the direction you are going to is always oriented toward the top of the screen. The direction information comes from the GPS device, and applications can access it from a liblocation structure.
Unfortunately, while this value is rather reliable when you are moving fast, it's totally pointless when you are not moving: and this can be easily seen in the alpha versions of Mapper, when the map starts spinning crazily as soon as you stop moving. One thing that I didn't notice is that besides giving the direction, liblocation also gives the estimated error: the epd field in the LocationGPSDeviceFix structure represents the error on the angle, as a value from 0 to 359. In my opinion it doesn't make much sense to have an error greater than 180 on an angle, so I assume that it must be divided by two.

In the image on the right, the epd is represented by 2 × β. Now, if v⃗₀is the current direction the map is oriented towards, and v⃗₁ is the new direction reported by the GPS with an error (uncertainty) of β, how do we decide if (and how much) we should rotate towards v⃗₁?
The algorithm I've implemented goes like this:

if β is greater than 90°, ignore the information altogether (i.e., don't change the rotation). Or,
if α (the angle between v⃗₀ and v⃗₁) is less than 5°, then let the map rotate to v⃗₁. Or,
rotate towards v⃗₁ by γ = α × ^{(90 - β)}⁄₉₀, that is the rotation is limited according to the error.

I've been testing the algorithm in the last few days, and it is indeed a huge improvement over the previous situation: now the map does not rotate while I'm not moving, or it does fairly seldom. But still, the map almost always rotates once just right after stopping, and not by a small amount, which is pretty annoying as it means that most of the times when you pause you'll have the map wrongly oriented — and pauses are usually the very moment when you'd look at the map...

I'll investigate this a bit more; this means that I'll have to keep a terminal window open with a view on the syslog, while using Mapper :-)

Mardy (Entratas super gps)

New website for Mappero Geotagger, and cross-compiling stuff

QBS and MXE

Fixing berserk rotations in Mapper