View Single Post
Posts: 1,548 | Thanked: 7,510 times | Joined on Apr 2010 @ Czech Republic
#474
Originally Posted by zimon View Post
That "log a track" was under the track which came from route (current route). When the route-track was followed, the log-track was only visible on some corners where there was GPS accuracy errors.Toggle would be nice to have the current log-track top most or bottom most.
BTW, there are currently 3 features that draw tracks on the map:
  • navigation - draws current route in blue color with yellow dots that represent turns
  • logging trace thats is drawn while logging is on (can be turned off) - light blue by default, but can be changed
  • drawing of saved tracklogs - multiple tracklogs can be displayed simultaneously, colors are chosen sequentially from a distinct colors set


Originally Posted by zimon View Post
I don't know if it is just me, but whole tracklogs thing seems rather messy UI-wise. There is "tracklogs" and "log a track" buttons in main menu, and behind "log a track" there is "tools" which then has "all tracks visible", "visible toggle", "set active" and so on - but what track for example is concerned with that "set active", the last one which was selected from "tracklogs" menu or the current one which is logging?
"set active" is used for setting an active track for the various info widgets (time to start/destination, route profile, etc.) and will be going away once the widgets are clickable.
But yeah, it is still messy - for example the "all tracks visible" should be really somewhere else, not in the tools submenu of every tracklog. I am thinking about sticking a "dashboard" menu behind the current tracklog button, with buttons like:
  • list tracklogs - the current tracklog list
  • list visible tracklogs - show a list of tracklogs that are currently being drawn on the map
  • show all on map - will show up only if some tracklogs are not visible
  • clear all from map - will show up only if some tracklogs are visible

Originally Posted by zimon View Post
What about this reroute "button" occupying so big area of the map when routing is active? Is rerouting needed so often it needs to be there, or could it be behind the [route info]-button, so one could more easily pan the map and not accidentally hit reroute?
It has been done like the to enable easy rerouting while driving - after missing an exit, etc. I'm going to implement automatic rerouting (just checking if you are inside a corridor around the route and trigger rerouting if you get outside of it) but I'll add a "reroute by taping the nav. info box" toggle in the meantime.

Originally Posted by zimon View Post
One more thing which I now remembered:
When log-tracking is turned on, but GPS-position hasn't not yet got, it draws the track log starting from the center of the country you are in. eCoach had this same problem few versions back but they fixed it.
I think I can check the accuracy of the GPS lock so this should be quite easy to fix.

Originally Posted by zimon View Post
Any info or idea (yet) what these GLIB warnings are, which are flooding dmesg?

Code:
Jan 12 02:21:11 Nokia-N900 python2.5[16693]: GLIB WARNING ** default - Trying to register gtype 'LocationGPSDeviceSet' as enum when in fact it is of type 'GFlags'
Jan 12 02:21:29 Nokia-N900 last message repeated 15 times
Jan 12 02:21:30 Nokia-N900 [1325]: GLIB DEBUG default - location-sb: fix status changed: 3->2
Jan 12 02:21:31 Nokia-N900 [1325]: GLIB DEBUG default - location-sb: fix status changed: 2->3
Jan 12 02:21:32 Nokia-N900 python2.5[16693]: GLIB WARNING ** default - Trying to register gtype 'LocationGPSDeviceSet' as enum when in fact it is of type 'GFlags'
Jan 12 02:21:42 Nokia-N900 last message repeated 9 times
Jan 12 02:21:42 Nokia-N900 [1325]: GLIB DEBUG default - location-sb: fix status changed: 3->2
Jan 12 02:21:43 Nokia-N900 [1325]: GLIB DEBUG default - location-sb: fix status changed: 2->3
Jan 12 02:21:44 Nokia-N900 python2.5[16693]: GLIB WARNING ** default - Trying to register gtype 'LocationGPSDeviceSet' as enum when in fact it is of type 'GFlags'
Id guess that this might be caused by the Python bindings for liblocation - modRana uses the liblocation bindings basically per the maemo wiki example.
You might want to try check if AGTL also causes this - it is IMHO written in Python so it is probably also using the same bindings for liblocation as modRana and might thus trigger the same issue.

I haven't been able to reproduce it myself yet - but I have only tested indoors so far - not outside with real GPS lock.
__________________
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)
 

The Following 2 Users Say Thank You to MartinK For This Useful Post: