Hi!
here is another big reason why we need navit.sh startup script:
if navit is already running it will start a second instance. thats not good.
=============================================================================
pgrep '^navit$'
not_running=$?
if [ $not_running == 0 ]; then
echo "navit already running !!"
else
echo "ok starting navit ..."
** start navit here ***
fi
=============================================================================
and if you want to start navit via dbus, e.g. from geocaching application so to
drive to a cache:
=============================================================================
#!/usr/bin/python
import dbus
import math
import sys
lat=float(sys.argv[1])
long=float(sys.argv[2])
bus = dbus.SessionBus()
conn = bus.get_object('org.navit_project.navit','/org/navit_project/navit')
iface = dbus.Interface(conn, dbus_interface='org.navit_project.navit');
iter=iface.iter();
navit=bus.get_object('org.navit_project.navit', conn.get_navit(iter));
iface.iter_destroy(iter);
navit_iface = dbus.Interface(navit,
dbus_interface='org.navit_project.navit.navit');
# Show a message in Navit
navit_iface.add_message("Geocache Ziel");
# M_PI=math.pi
M_PI=3.1415926535897931
# M_PI_4=math.pi/4
M_PI_4=0.78539816339744828
# x=long*6371000.0*float(M_PI)/float(180)
x=long*111194.92664455873
y=math.log(math.tan(M_PI_4+lat*M_PI/360))*6371000.0
# Set as route destination
navit_iface.set_destination((1,int(x),int(y)),'geocache');
=============================================================================
then without navit.sh it will start a second navit program (maybe we should
request single instance from navit devs?)
also its not clear which navit will be started by dbus. its in this file
"org.navit_project.navit.service"
=============================================================================
[D-BUS Service]
Name=org.navit_project.navit
Exec=/usr/bin/navit
=============================================================================
thats the only unclear thing when you install more than 1 version of navit.
Sebastian Spaeth wrote:
> On 01/08/10 11:17, Zoff wrote:
>> you install ONLY 1 package -> (example): navit-austria-car
>
> Yep, these type of meta-packages would be useful and should be done. Can you
> open a trac ticket about that? The only problem is that this is a maintenance
> nightmare. It is hard enough to keep one
> configuration of navit up to date, with that we have to do the same stuff
> 5-times ...
>
thanks for finding my idea useful. thats a start :-)
i dont think it would be so hard to maintain.
navit-austria-car e.g. should only contain small things that are important for
austria.
the only things in that package would be:
*) dependency on the correct locale (de_AT.UTF-8)
*) the startup call in the desktop file (use right config, get Display resource
via fsoraw)
*) the desktop icon (so to see what version you will start. e.g. german flag or
car-icon or whatever)
*) the location of the *.bin file (austria.bin or europe.bin)
*) a shell script to update/download the correct *.bin file to the correct
directory (get it via wget from http://maps.navit-project.org/api/map/?bbox=)
*) some .xml include file to get set car profile
*) maybe a startup location somewhere in austria (optional)
-----> those should never have to be changed (almost never)
but i have done this already (well 96%) and it was thrown out completely.
but if useful i sure would maintain the austria and german
*.bb files (maybe JaMa would rather like to maintain the german one, also the
german-bike one ?)
>> "Make sure, that LC_ALL ist not set though.
>> Otherwise navit fails to interprete gpsd output and you end up with
>> strange gps coordinates."
> ...
>
>> so i think we should not try to be smarter than the navit devs :-)
>
> No we should not, but LC_ALL should also not be set. It is not set here on my
> freerunner.
well ok thats a good point. so its fine then.
>
>>> Ususally, an app that has to touch LC_ALL, is pretty much broken.
>>> If you convince us that it is actually useful and needed, then let us
>>> simply add it to our .desktop file.
>> here you are wrong, i wrote about this maybe 10 times. but nobody will
>> listen.
>> e17 sets the LC_* vars wrong! (when you dont use en_US)
>
> That does sound like illume is pretty much broken there. I only use the
> en_US, so I can't say anything about the rest.
yeah. there is mention of old version of englightenment_remote still available
as _old , but i cant find it anywhere.
why is the LC_* not settable via keyboard, so that i can enter a custom string?
also (i made a ticket about this i think) the changes should be pinned to
/etc/profile. so that you can also start things
from /etc/init.d/* or from shell with the correct locale.
this is all really really basic stuff. somebody fix that please.
>
> spaetz
Z.
--
"My malpractice insurance doesn’t cover alien autopsies."
_______________________________________________
Shr-devel mailing list
[email protected]
http://lists.shr-project.org/mailman/listinfo/shr-devel