Opened 11 years ago

Closed 9 years ago

#439 closed defect/bug (fixed)

manual setting of country necessary

Reported by: arne.anka Owned by: KaZeR
Priority: major Milestone: version 0.5.0
Component: core Version: git master
Severity: Keywords:
Cc:

Description

after a lot of searching (documentation could be way better!), i found, that navit looks for $LANG to determine the country one's in.

i strongly urge, to let the user make that kind of decision! for over ten years now i use english as language of all my computers and have the locale set to en_DK because that's the closest matching locale to english desktop and german collation and so on. because of the inflexible way navit tries to impose its idea of my country, navit is always convinced, i am in denmark -- and there's no way to tell navit off.

using LANG=C for experiments sake, offers the grey X allowing the selection of my country. why isn't that enabled by default? if you absolutely must use some kind of hardcoded country (why?) it should be set in navit.xml. users know that navit.xml is the configuration file for navit and expect, relevant information to be set there.

using an in no way related environment variable (what du you do with, say, a french living in russia but using fr_FR as locale?) is intransparent and almost impossible to find out, since it is very badly documented.

decisions like that should never be left to some obscure automatism, but made visible to the user.

so, to make it short

  • enable selection of country always
  • create ne tag in navit.xml to set default country

btw: yes, i read #276 and #354.

Change History (12)

comment:1 Changed 11 years ago by sera

Like two weeks ago I had the same discussion. The final solution has to look different. But beware this is alpha software and hacks like that (using $LANG) are sometimes viable choices. The same goes for documentation.

My current proposal is to introduce a state-full town search. Imagine a taxi driver witch never leaves the city and still has to set country and city each time. Imagine a tiny touchscreen and huge fingers, a wrong "key press" might result in having to start over again.

The search struct would be initialized at startup from navit.xml allowing the user to configure the default country freely, actually to configure the initial search state.

The country_default() function in country.c would then look something like this:

1. use the environment variable NAVIT_DEFAULT_COUNTRY if present.
2. else use the country code for an unknown country (or the country of the original developer).

Deprecating country_default() is possible too. Otherwise it's at least guaranteed to return a valid country code and could be used at start up if there is no default country specified in navit.xml.

comment:2 Changed 11 years ago by stuvel.eu

I agree that the whole LANG thing is a kludge.

As an alternative to step 2 of the above "algorithm" I would suggest "Use the country the active vehicle is in at this moment". I think it's most likely that a user is searching for a town in his/her own country.

A stateful town search would be very nice. Please also keep an eye open at #419 and #446 when thinking about this ticket.

comment:3 Changed 11 years ago by stuvel.eu

About the stateful menu: I've added a feature request ticket for this, #448

comment:4 Changed 11 years ago by arne.anka

step 2 would require the user to wait until the device got a fix -- which may take a rather long time (comparatively, at least).

comment:5 follow-up: Changed 11 years ago by stuvel.eu

That can be easily solved by caching the country ID. Most people don't change countries that often to make this a real problem. If the user can also override the country that is searched by clicking the flag/cross, I don't see a problem at all.

This hooks in to making Navit more stateful. When the user changes the country to be searched (let's call it $TOSEARCH), I reckon this should be saved on disk, and restored when Navit restarts.

This leaves the matter of having two sources of $TOSEARCH, the chosen country and the current country according to the GPS (let's call it $GPS_COUNTRY). When $GPS_COUNTRY changes, and the old value of $GPS_COUNTRY == $TOSEARCH, we could assume that the user wants to search the current country, and set $TOSEARCH to the new value of $GPS_COUNTRY. Otherwise we should keep $TOSEARCH to its old value, and provide a simple way of setting it to $GPS_COUNTRY.

That's my idea, at least.

comment:6 in reply to: ↑ 5 ; follow-up: Changed 11 years ago by sera

Replying to http://stuvel.eu/:

This leaves the matter of having two sources of $TOSEARCH, the chosen country and the current country according to the GPS (let's call it $GPS_COUNTRY). When $GPS_COUNTRY changes, and the old value of $GPS_COUNTRY == $TOSEARCH, we could assume that the user wants to search the current country, and set $TOSEARCH to the new value of $GPS_COUNTRY. Otherwise we should keep $TOSEARCH to its old value, and provide a simple way of setting it to $GPS_COUNTRY.

This sounds like trying to be to clever. The assumption of the user wanting to search in $gps_country does not hold. Maybe I'm planing holidays and I'm using navit only for it's routing capabilities. Do I have now to set the country each time I want to enter a start or an end point because navit assumes so? What about multiple vehicles? There is no defined order. What happens when they are not in the same country? What if no country is specified in navit.xml and there is no vehicle or the gps doesn't get a fix? Making the menu state full already means there is the need for more navigation elements in the UI. For the internal gui adding a shortcut means taking even more of the sparse space for a rare use case when a generic back button, pressing once or twice a letter and choosing from a list do the same.

Also using $gps_country does not replace step 2. witch is meant to allocate the ram and put a valid country code in there at startup. Later there is no need to test for existence and validity and failed attempts to use this value should result in navit dying. Less bug-prone and user friendlier (a hint to a not configured feature if using a special flag for an unknown county witch itself has a valid country code).

I think it's most likely that a user is searching for a town in his/her own country.

That's the reason why people will set their country as default in navit.xml and relying on the gps isn't necessary. For unix folks there is the $ENV goody. Currently I would tend to remove country_default() completely and put the relevant bits (step 2.) in the startup code.

BTW: nice examples in bug 488.

comment:7 in reply to: ↑ 6 Changed 11 years ago by stuvel.eu

Replying to sera:

This sounds like trying to be to clever.

Yup, I feel that software should be as clever as possible without getting in the way.

The assumption of the user wanting to search in $gps_country does not hold.

IMO we should make sure that the common case is very easy to use. The average user of GPS navigation software will have one GPS and probably navigate in the country they are in at the moment. This is a use case we should at least support by having smart implementation. Whether that implementation is hardcoded to be always enabled is something we'll have to discuss (probably not here nor now).

Maybe I'm planing holidays and I'm using navit only for it's routing capabilities. Do I have now to set the country each time I want to enter a start or an end point because navit assumes so?

If that's annoying: no, we don't want that. But if we can add behaviour that is very useful in the common case, and can be turned off in the less common case, I don't see why we should shy away from that.

What about multiple vehicles? There is no defined order. What happens when they are not in the same country?

Only the active vehicle is used for routing, so I wouldn't be surprised if the active vehicle was used for determining the active country.

What if no country is specified in navit.xml and there is no vehicle or the gps doesn't get a fix?

Behaviour just like it is now.

Making the menu state full already means there is the need for more navigation elements in the UI.

My idea was this:

  • The globe icon returns the user to the map.
  • Clicking on the map shows the menu in exactly the same state as it was when the globe icon was clicked.

This introduces no new GUI elements, but makes the menu stateful. Maybe I don't understand you correctly, if so please elaborate what kind of statefulness of exactly which menu you mean.

Also using $gps_country does not replace step 2. which is meant to allocate the ram and put a valid country code in there at startup. Later there is no need to test for existence and validity and failed attempts to use this value should result in navit dying.

When discussing what kind of behaviour we want, I don't want to bother myself with implementation details. When a certain behaviour is chosen, the software can be modified to support that behaviour. An easy solution would be to add a default country to the configuration file and add an option "use current country=(boolean)". It's software - every behaviour we can think of can be implemented.

Less bug-prone

... is actually placing comments in the code, ensuring the DTD is up to date, and using unit tests to ensure a change doesn't break existing code. Let's not go into details about where bugs may occur if we're not even agreeing on what kind of behaviour we want.

I think it's most likely that a user is searching for a town in his/her own country.

That's the reason why people will set their country as default in navit.xml and relying on the gps isn't necessary. For unix folks there is the $ENV goody.

I don't see why the country to search in is so different from all the other configuration that it shouldn't be in the navit.xml file. At this moment I have two icons on my phone, one that starts Navit with default_country=France and one that starts Navit with default_country=Netherlands. I don't want to create a new desktop icon just to change the environment variable that controls the country I search in. I want to use the Navit UI to select a country, and have that country the default country the next time I start Navit. Navit can write a state file, it could (should?) even be able to write its own configuration file. Is it so strange that a piece of software can remember its own settings? It does so for the location it centres the map on, why not for the selected country as well? The "map centre" configuration shows exactly the kind of statefulness I would expect in other areas as well, such as:

  • Current country to search in
  • 2D or 3D view
  • Full screen or not
  • Activated/deactivated rules
  • etc.

BTW: nice examples in bug 488.

Thanks.

comment:8 Changed 10 years ago by gabor

Theoretical disputes about the Right Thing aside, here's a workaround:

echo '#!/bin/sh' > /usr/bin/navit.de # Put your default country of choice here: echo 'export LANG=de_DE.UTF-8' >> /usr/bin/navit.de echo 'exec navit' >> /usr/bin/navit.de chmod 755 /usr/bin/navit.de sed -i 's/Exec=navit$/Exec=navit.de/' /uasr/share/applications/navit.desktop

Minor drawback: if you actually have de_DE locale installed, Navit will switch to german.

comment:9 Changed 10 years ago by gabor

Sorry, forgot to make it 'code':

echo '#!/bin/sh' > /usr/bin/navit.de 
# Put your default country of choice here: 
echo 'export LANG=de_DE.UTF-8' >> /usr/bin/navit.de 
echo 'exec navit' >> /usr/bin/navit.de 
chmod 755 /usr/bin/navit.de 
sed -i 's/Exec=navit$/Exec=navit.de/' /usr/share/applications/navit.desktop

comment:10 Changed 9 years ago by kazer

  • Milestone set to version 0.3.0

0.2-* releases will be mainly bugfixes. We'll try to do something better for 0.3

comment:11 Changed 9 years ago by korrosa

Not sure if you guys are aware, but you can specify a language within the <config> tag of navit.xml (this info was gleaned from irc conversations).

For example, <config ... language="en_US"> will provide you with US English, and set the country to USA. I haven't tried this myself, though....

I documented it yesterday at http://wiki.navit-project.org/index.php/Configuring_Navit#Full_List_of_Options

comment:12 Changed 9 years ago by korrosa

  • Resolution set to fixed
  • Status changed from new to closed

I can confirm that <config ... language="en_US"> works absolutely fine. I also tried language="de_DE", language="fr_BE" and language="nl_BE" and these work as expected for the purposes of this ticket.

Note: See TracTickets for help on using tickets.