version 2.13.0
after three weeks, new version, enjoy!
News: http://www.locusmap.eu/news-in-versio...
add: OSM Notes support (instead of deprecated OSM bugs)
add: (PRO) ability to change icons for more points at once
add: added support for sorting by number of favorite points (geocaching)
chg: improved "Data" screen (and merged with removed "Items visibility")
chg: improved POI filter (mainly for a geocaching)
chg: improved "Always screen on" settings
chg: improved speed of "remove before" and "remove after" function in track editor
chg: improvements in "Backup manager"
and mainly many many speed optimizations, like faster loading points/tracks, faster map move, little bit faster vector maps rendering, memory optimizations, many small fixes and more
In Polish language date format was better in previous version. Actually - 18:10, Month Day, past - Day Month Year 18:10.
I prefer "|" in cords instead of ",". Actually - N 52.26.710` , E 16.56.150`. Better - N 52.26.710` | E 16.56.150`
In Polish language date format was better in previous version. Actually - 18:10, Month Day, past - Day Month Year 18:10.
I prefer "|" in cords instead of ",". Actually - N 52.26.710` , E 16.56.150`. Better - N 52.26.710` | E 16.56.150`
hi,
date format on some places should be now generated by your own device. This means that is should look as expected in used language. Where you see this datum? I`ll rather check it`s format
and about separator ... why you prefer "|"? Because I had quite long discussion with one guy. He copied this text " N 52.26.710` | E 16.56.150` " into another softwares and non of them was able to recognize coordinates just because of this
EDIT: I was searching for a way to define some universal date/time format but seems it`s more complicated then I expect http://en.wikipedia.org/wiki/Date_for...
So in next version I try to generate this format automatically in better way to best fir users locale and we`ll see. Anyway it will be "date, time", not opposite as now. I agree that date is more important and should be first
hi,
date format on some places should be now generated by your own device. This means that is should look as expected in used language. Where you see this datum? I`ll rather check it`s format
and about separator ... why you prefer "|"? Because I had quite long discussion with one guy. He copied this text " N 52.26.710` | E 16.56.150` " into another softwares and non of them was able to recognize coordinates just because of this
EDIT: I was searching for a way to define some universal date/time format but seems it`s more complicated then I expect http://en.wikipedia.org/wiki/Date_for...
So in next version I try to generate this format automatically in better way to best fir users locale and we`ll see. Anyway it will be "date, time", not opposite as now. I agree that date is more important and should be first
This date is in point/geocaching screen. It`s strange, but this date format is only in Locus, other apps and system use standard - DD.MM.YYYY, HH:MM.
I prefer "|", because comma looks like dot, and there is space betwen " ` " and ",", so all it`s not for fast view.
Maybe remove comma will be good idea or divide coords by enter.
Another bug? When browse map, with geocaching points, center cross not show name of point, when too fast scrool map. This happen only on this version, sometimes cross don`t show name even when stop it on point.
This date is in point/geocaching screen. It`s strange, but this date format is only in Locus, other apps and system use standard - DD.MM.YYYY, HH:MM.
I prefer "|", because comma looks like dot, and there is space betwen " ` " and ",", so all it`s not for fast view.
Maybe remove comma will be good idea or divide coords by enter.
Another bug? When browse map, with geocaching points, center cross not show name of point, when too fast scrool map. This happen only on this version, sometimes cross don`t show name even when stop it on point.
understand .. about times I wrote above, about separator - I`ll think about it
and bug - nono, it`s intent. If you move fast, you do not need to highlight all items that you move over, so there is many new optimizations that dramatically increase speed and reduce lags. Anyway if you stop on any point and you still don`t see a name, it`s a bug. I`ll be be aware of it and try to fix
understand .. about times I wrote above, about separator - I`ll think about it
and bug - nono, it`s intent. If you move fast, you do not need to highlight all items that you move over, so there is many new optimizations that dramatically increase speed and reduce lags. Anyway if you stop on any point and you still don`t see a name, it`s a bug. I`ll be be aware of it and try to fix
In the waypoint & track lists, one can quickly enable/disable all items now by simply clicking on the symbol. Nice idea... maybe... HOWEVER...
... enabling/disabling all items in a folder can render Locus completely useless for many minutes and even make it crash. This is due to the inefficient way that Locus handles track selection (scanning all points?). So right now, just slightly "mis"clicking a folder name a bit too far on the left can result in a majorly long delay.
If you make the "select all" function so easily available, you need to make sure it is always instant. Rendering my phone useless for minutes just because my fingers are slightly shaky when trying to enter a folder on a moving bicycle is not an option :).
In the waypoint & track lists, one can quickly enable/disable all items now by simply clicking on the symbol. Nice idea... maybe... HOWEVER...
... enabling/disabling all items in a folder can render Locus completely useless for many minutes and even make it crash. This is due to the inefficient way that Locus handles track selection (scanning all points?). So right now, just slightly "mis"clicking a folder name a bit too far on the left can result in a majorly long delay.
If you make the "select all" function so easily available, you need to make sure it is always instant. Rendering my phone useless for minutes just because my fingers are slightly shaky when trying to enter a folder on a moving bicycle is not an option :).
"always instant" is impossible. Current speed is probably max, I can for now get from Android SQLite database
But you`re of course right that by accident, you may wait quite a long. So you forced me to create long await possibility to cancel some long running tasks ...
"always instant" is impossible. Current speed is probably max, I can for now get from Android SQLite database
But you`re of course right that by accident, you may wait quite a long. So you forced me to create long await possibility to cancel some long running tasks ...
Cancel is certainly an improvement, it makes a horrible thing a little less horrible.
I still dont understand why the time required for track selection depends on the size of the track. Why do you need to read every single point for that operation? And why does it have to be done by the user interface task? The only visible change on screen is a tiny checkmark. Its utterly confusing to a user why this should take so long. Whatever goes on "behind the scenes" should not block the UI.
Imagine a file explorer reading every single byte of a file when multiselecting... what a horribly crazy thing to do that would be. Yet Locus seems to be designed to do exactly that :-).
Cancel is certainly an improvement, it makes a horrible thing a little less horrible.
I still dont understand why the time required for track selection depends on the size of the track. Why do you need to read every single point for that operation? And why does it have to be done by the user interface task? The only visible change on screen is a tiny checkmark. Its utterly confusing to a user why this should take so long. Whatever goes on "behind the scenes" should not block the UI.
Imagine a file explorer reading every single byte of a file when multiselecting... what a horribly crazy thing to do that would be. Yet Locus seems to be designed to do exactly that :-).
yes it do, because you probably do not noticed, but by checking a track, it`s also loaded on map. There is no difference between "check to just select" and "check to load on map"
yes it do, because you probably do not noticed, but by checking a track, it`s also loaded on map. There is no difference between "check to just select" and "check to load on map"
Sure there is no difference... and that is good. But the map is not even visible when I select tracks in a list! And even if it was, why isnt this tedious loading work done in the background? There is no reason to block the UI... none at all... except simpler programming :-).
I admit having very strong opinions about that... but I hate every single occasion when an app forces me to wait. This is exactly what makes the difference between a snappy UI and something rather cumbersome.
And this isnt just a random, lonely, seldomly used place in Locus... the track list is very central to me. It happens quite often that I simply want to move a bunch of tracks to other folders, or delete a few, or enable a few, or disable a few. Unfortunately, Locus turns something that should take a second or two into a tedious half-minute-long-operation. And thats on one of the fastest phones available today, I dont even want to imagine how it feels on mid-range devices.
To clarify: I understand completely that the process of loading up tracks for display takes a long time and requires plenty resources... nothing wrong with that. But it is certainly wrong to do this work on the UI task and make users wait for its completion after every single tap.
Sure there is no difference... and that is good. But the map is not even visible when I select tracks in a list! And even if it was, why isnt this tedious loading work done in the background? There is no reason to block the UI... none at all... except simpler programming :-).
I admit having very strong opinions about that... but I hate every single occasion when an app forces me to wait. This is exactly what makes the difference between a snappy UI and something rather cumbersome.
And this isnt just a random, lonely, seldomly used place in Locus... the track list is very central to me. It happens quite often that I simply want to move a bunch of tracks to other folders, or delete a few, or enable a few, or disable a few. Unfortunately, Locus turns something that should take a second or two into a tedious half-minute-long-operation. And thats on one of the fastest phones available today, I dont even want to imagine how it feels on mid-range devices.
To clarify: I understand completely that the process of loading up tracks for display takes a long time and requires plenty resources... nothing wrong with that. But it is certainly wrong to do this work on the UI task and make users wait for its completion after every single tap.
oki, I understand your thought and agree. Fortunately we already have a topic about it here https://getsatisfaction.com/locus/top...
oki, I understand your thought and agree. Fortunately we already have a topic about it here https://getsatisfaction.com/locus/top...
Concerning about "date, time" format, if android system locale is set to Japan,
it is now "2013/07/08, 23:59". I say that the order of date and time is proper for Japanese language.
It`s really nice because the format is affected not only at the top panel but also items/tracks info, backup manager, and etc.
But only in the Weather panel, the format is not affected and it`s still strange.
Please have a look at there, too.
Thanks in advance.
Concerning about "date, time" format, if android system locale is set to Japan,
it is now "2013/07/08, 23:59". I say that the order of date and time is proper for Japanese language.
It`s really nice because the format is affected not only at the top panel but also items/tracks info, backup manager, and etc.
But only in the Weather panel, the format is not affected and it`s still strange.
Please have a look at there, too.
Thanks in advance.
Replies have been locked on this page!