Rob Norris [Wed, 11 Aug 2010 20:49:28 +0000 (21:49 +0100)]
Add internal function to insert a trackpoint after the currently selected trackpoint.
The new trackpoint is interpolated between the current trackpoint and the next trackpoint.
All applicable values are interpolated: position, altitude, time, speed & course.
'Extended' properties such as number of sats & HDOP are left at defaults.
This method works for newly created tracks, as well as real tracks from a GPS.
I feel that this new change helps to keep code as simple as possible.
There's no need to give VikTrack in argument as VikTrack can be
retrieve from VikTrwLayer with trackname.
Furthermore, deciding to export track as GPX without new file type
value.
Rob Norris [Sun, 12 Sep 2010 09:34:19 +0000 (10:34 +0100)]
Enable individual track to GPX export via the Track sublayer menu.
Internally gpx.[ch] supports writing a track to the specified file, so make this available in the GUI.
Expand export definitions in file.h, use the gpx.h interface as necessary routing via a_file_export function.
Filename used is automatically generated from the track name with a '.gpx' appended if appropriate.
Restructure trw_layer_export function to support passing track information.
Add the new sublayer menu entry to use this feature.
Rob Norris [Mon, 5 Jul 2010 23:10:30 +0000 (00:10 +0100)]
Add a perl script to auto generate basic Viking .vik files for directories containing images.
Simply recursively search down the directory tree (from the current location) for suitable image files
[normally jpg|JPG (probably photographs)] and then extract any location data from the EXIF part.
For each directory this info is output to a file into either Viking (default) or GPX data file formats.
Output filename is waypoints.vik (or waypoints.gpx in GPX mode) unless the -o option is specified.
Rob Norris [Thu, 18 Nov 2010 23:18:46 +0000 (23:18 +0000)]
Enable control of the visibility of the menubar [including keyboard shortcut - F4].
Also enable panic key 'Escape' to restore menubar if hidden and no tool uses it.
I tried to explore Git in order to identify copyright related issues.
The result is quite incomplete or incoherent: the changes I made does
not use strict rules. So, I hope I did not irritate anybody.
If you think your name should be listed somewhere, or should be removed,
send the patch.
Rob Norris [Fri, 15 Oct 2010 19:19:17 +0000 (20:19 +0100)]
Various improvements and tidy ups.
Improve concepts:
. Add what is a Layer
. Mention Statusbar
Better use of 'appname'
Move verbose/debug mode to bottom + add example for a map download
General GUI reference improvements.
Add Begin Track Icon.
Other misc bits as I went along...
Rob Norris [Sun, 31 Oct 2010 20:11:44 +0000 (20:11 +0000)]
Fix extend track using magic scissors.
Should only need to click once to select the next point to extend the current track, hence need to mark that the first point is known (via the 'magic scissors started' variable).
Sven Wegener [Thu, 14 Oct 2010 19:46:11 +0000 (21:46 +0200)]
Fix autodownloading while panning
Since commit 1c6a6010 ("Disable autodownloading when dragging the map")
we only trigger an autodownload when starting to pan and not on stop,
which is pretty bad. Also pan_move is never reset, resulting in no
update when panning with keyboard shortcuts after panning with the
mouse.
Signed-off-by: Sven Wegener <sven.wegener@stealer.net>
Rob Norris [Mon, 18 Oct 2010 19:25:51 +0000 (20:25 +0100)]
Prevent crashes when downloading Expedia Maps.
Fix expedia code to use updated vikmapslayer_compat.h, which was modified for:
'Allow reuse of curl connection objects'
SHA: 825413bac81e7234ed27a8ff3343a8295cc393e2
Jon Burgess [Sun, 26 Sep 2010 14:25:28 +0000 (16:25 +0200)]
Fix memcheck error
What I think happens is:
1) We first do a request for a tile with an ETag and apply a custom
header, this gets set into the conn->data->set.headers pointer
2) The header gets freed, but the set.headers pointer is left as a
dangling reference to the memory
3) A subsequent request is generated for a tile without an etag so we do
not overwrite the set.headers pointer and it keeps the old, invalid
value and the HTTP request code tries to reference it.
I believe the associated change should fix it by ensuring the dangling
pointer gets cleared during step (2).
I recently discovered that a recent commit introduce a significant
change on CPU usage.
The commit is 71eff775d86be02173e28421cea7f7d3f5a8344. It offers a
smooth pan when drag&drop, but it introduces a huge amount of tile
requests.
For exemple, when I drag the map, I quickly observe around 600
requests on local tile cache while around 10 requests would be enough.
The matter is, in order to keep a smooth dragging, the viewport is
requested to redraw completly. While doing this, all displayed maps
need to check their local cache. And this, for each X event.
This fix is a temporary one.
A better solution implies certainly a significant refactoring
of display/download.
This commit introduced a behaviour quite confusing: a saved .vik file
cannot be reopened after a change on prefered cache directory.
At least the old way is deterministic.
Rob Norris [Thu, 30 Sep 2010 20:51:32 +0000 (21:51 +0100)]
Make more portable .vik file, as don't save the map cache directory if it's the map cache default directory.
The map cache default directory is dependent on the user and OS, however on reading in when it's blank it automatically puts in the map cache default directory.
Jon Burgess [Sun, 26 Sep 2010 18:51:43 +0000 (19:51 +0100)]
Prevent access to undefined data when fgets() returns NULL
If viking.prefs is empty this triggers the following warning at startup in valgrind:
==21725== Conditional jump or move depends on uninitialised value(s)
==21725== at 0x447354: preferences_load_from_file (preferences.c:147)
==21725== by 0x447444: a_preferences_get (preferences.c:318)
==21725== by 0x41019D: a_vik_get_default_lat (globals.c:133)
==21725== by 0x42B6F3: viewport_init (vikviewport.c:167)
...
This occurs when fgets() returns NULL but the code still tries to
interpret the uninitialized contents of buf.
The minimum speed difference is far too great so reduce from 20m/s to 5m/s, otherwise the values shown can be very small compared to the overall graph maximum. For tracks with a bigger difference it automatically uses a sensible difference.
Rob Norris [Sun, 26 Sep 2010 18:15:49 +0000 (19:15 +0100)]
Use speed units in display of Track/Waypoint layer draw by velocity config values, but maintain units as metres per second when read from/saved to files.