unav-devs team mailing list archive

[Costales <costales@xxxxxxxxxx>]

Hi :)


>>> 1. The "analyzing speed cameras for longer trips takes annoying long
>>> time with the app not responding to any input.

I saw it 2 months ago and I improved to show the message.
It's so complicate to fix that because there so many speed camera POIs
and we need to filter who of them are in the route.
I was thinking in doesn't merge, but the CPU load would be in each
position and this would be so worst.
In my tests, 600km of route, analizing them should be ~30 seconds. I
think in Germany there are more speed cameras :P
I'll think on it again, but I'm afraid that it's not a good solution
about this :(


>>> --> Might it be possible to send this function into background !?


It could be a possible solution, but a independent javascript thread
would be so complicate of debug if we have a problem in the future.



How many time took the check of speed cameras in your case?



>>>     if not in the js, maybe we can do it on qml level and send the
>>> results
>>> back to the webview.



Avoid QML <> HTML calls as we can ;) They are not good friends :P





>>> 2. There are states, where the app those not return a gps signal anymore.
>>> This seems not to be related to the gps-service, as restarting the app
>>> leads to a clear signal again.


Probably it is this bug or the next I'm telling you:
https://bugs.launchpad.net/unav/+bug/1562783


I'm not happy with 2 bugs:
- New bug: uNav doesn't receive new positions. The difference between
#1562783 is that uNav is not freeze, you know that because you can
drag the map.
If you cancel the route and set it again, the new message "GSP denied"
will appears. The GPS is died! :@

- This white map:
https://bugs.launchpad.net/ubuntu/+source/oxide-qt/+bug/1375215 It
isn't fixed in uNav and I think is the same issue.


I'll write to the mail list and create 3 new bugs this afternoon. But
we can't do anything from unav about all of them :((

Thanks a lot for your feedback Joerg!