The recent 0.3 release of MoNav provides a useful interface, which allows to invoke all features directly from its main window. It’s a great, both finger as well as user friendly interface, especially on mobile devices such as the Nokia N900. The downside is that it does not conform to the look and feel of the other applications of a given platform.
An end user, who has no clue about software development, will never understand why »there is this cool app foo, but it only is available on platform bar.«. On the other hand, a software developer who has written this cool code foo may want to make it run on as many platforms as possible.
Back in the days I contributed code to Navit, it provided a plugin system for its user interface. Though this might have changed, none of them really served me well at that time.
What does this mean for my currently favourite pet project, MoNav? I’m currently doing exactly what Martin objects to (with reason). I try to create a user interface which contains the usual UI controls other applications provide – toolbars, menubars, you name it. I add some defines to make the user interface a bit more conformant on Maemo, then Android, then Win and finally Mac OS X. One day I will notice that editing the code without breaking the user interface of a particular platform becomes more and more difficult.
MoNav already provides a backend only process for calculating routes. Theoretically it was simple to build a web application using the toolkit used, Qt. But transforming an application like MoNav within one minor release is not what you really can do in your spare time. As a consequence, MoNav will keep it’s current cross platform user interface for some time.
User Interface Changes
What follows will probably form the base of the upcoming 0.4 release. The buttons spread over the viewport have disappeared. Instead, a toolbar as found in other Maemo applications has been introduced:
I removed the possibility to add buttons for each via point. Instead, the button to select the destination of the route now provides several modes. One lets the user create a direct route to the destination. A second option can be used to create incremental routes (»From my home to the viewpoint to the biergarten and back home.«). A third one lets the user insert points between the current location and the destination (»From my home back home, but first to the viewpoint and then to the biergarten.«). I’m not sure whether those modes will make it into the final 0.4 release. Currently it’s there to be tested, mainly by myself:
On the desktop (Win, Ubuntu) MoNav now provides standard menus. On Maemo, which does not provide standard menus but one united menu only, it now looks like the following figure. Please ignore the Trip Information and the placeholder button, as those are only there for experimental features I’m currently hacking :) :
The new user interface has its advantages and its disadvantages. I’ll use it for the next couple of weeks to determine whether it is better than the previous one or not.
In case you want to try it as well, you’ll need to compile it from source. As the repository recently was switched from SVN to Mercurial, you’ll need it installed on your system. The following example commands are untested and only provided as examples:
hg clone https://monav.googlecode.com/hg/ monav
hg update -C ui-ng
qmake monavclient.pro && make(for Maemo)
qmake DEFINES+=NOQTMOBILE monavclient.pro && make(Linux Desktop)
qmake DEFINES+=NOQTMOBILE monavclient.pro && mingw32-make(Win Desktop)
qmake DEFINES+=NOQTMOBILE monavclient.pro -spec macx-g++ && make(Mac Desktop)
In case you find MoNav interesting and you want to contribute, do not hesitate to contact us. Besides other many other things, someone who cares about the Android port or creates a professional icon set to replace the current artefacts would be more than welcome. The current renderer could need some improvements (rendering of street names, for example), and there’s a possible alternative to it called libosmscout.