Prune is available to download from the downloads page, with the latest released version being version 8. Details of the development of version 9 are given here, with a release coming in February 2010.
Don't forget, any help with the translations is always very welcome, especially to finish the last few Italian and French texts, and to complete the Chinese and Spanish texts. Please see the translation wiki for details on how to help with this.
The texts have now been frozen for version 9, so please help with the translations so that they can be included in time. No new texts will be added now, so the translations are just waiting to be done!
The following is a preview release of version 9 for testing - please be aware that this may well contain bugs of unknown nastiness. If you want to help with testing, please try it out and send back reports of any bugs you find (either by email or via the forums at sourceforge).
Runnable code for testing (520 kb) |
Here is a list of enhancements and extra features under discussion for version 9:
The idea of maintaining a "library" of previously-loaded tracks to find nearby data etc, and the proposal to hold multiple tracks rather than just one have both been shelved for now. Also the idea to "upload links to online resources like gpsies.com, openstreetmap" won't make it into version 9 - isn't saving from Prune and uploading to those resources easy enough anyway? Similarly, the suggestion to implement colour coding in the KML export like gpsvisualizer does" has been shelved, you can use gpsvisualizer on Prune's output for now anyway.
See also the wishlist for new features which have been proposed by users of Prune.
Progress has been held up a little since version 8 was released, due to Beaver and other projects. But we've had some small updates to the Romanian texts, and waypoint types are now read in from gpx files if present, and displayed in the details panel. So they can be saved back to gpx or as text, or read from text and saved to gpx.
There's also been some talk about error messages from exiftool, and how to report them in Prune if the exif write fails. There's now a simple error message but perhaps it should also capture the error from exiftool and display it. Anyway, it gives an error if any of the writes fail, and with an extra checkbox you can force the write (using exiftool's -m parameter) in which case Prune will tell you how many of the writes it had to force.
Also there's the option to open Bing maps in a browser now (along with the openstreetmap, google, mapquest and yahoo options), and a new function to convert waypoint names into timestamps. Now, that may seem an odd thing to want to do, but there are devices out there which save their timestamps as a waypoint name, for example in kml format. So this option, applied to the current selection, lets you turn it back into a track with timestamps (and hence with speeds and durations) rather than a set of waypoints. Of course you could do that with version 8 too, by saving it as text and then reopening it with differently specified fields, but this new way makes it much easier and lets you do the conversion just for a selection of the data.
As an added bonus, you can now load gzipped gpx or kml files transparently from the open files dialog, in the same way that zipped xml files can be loaded. So for those who have gpx.gz files, you now don't need to gunzip them before loading into Prune.
Another new feature is user-definable colour schemes (illustrated on the right), so if you happen to not like white backgrounds and black text on your maps, you can change them. In all, eight colours are defined, and used by the main map and the altitude profile. Of course, this includes the blue for the track points and green for the selected range. They are also saved when you do a "save settings" and reloaded next time. Unfortunately, and rather astonishingly, there are serious bugs with the standard JColorChooser in java 1.6, causing frequent complete deadlocking of the application, so this can't be used. Instead, there's just a simple colour choosing dialog with sliders for red, green and blue values.
One of the items on the wishlist was the ability to paste in coordinates from geocaching websites. As an example, opencaching.de provides free coordinates in the form "N 53° 10.928' E 004° 51.319'". On the other hand, sites like wikipedia give their coordinates in the form "46° 29' 54" N, 7° 43' 37" E". So any paste function would have to cope with various coordinate formats, comma separators or just spaces, and maybe even altitudes too for some caches. It is rather awkward to save such coordinate snippets to a text file, insert the separators if necessary, and then select that file in Prune to open it, so it's a great improvement now that the paste function is working. It is quite flexible with regard to coordinate format and field order, and can cope with both the above formats and many more variations. Unfortunately many of the geocaching websites require registration to browse their data so it's difficult to test against all the currently used formats.
There was also a wish to retain all the contents of gpx files, including those tags currently ignored by Prune. The first step towards this is that the "load from GPS" function now has a checkbox to let you save the output of gpsbabel directly to a file, so you're sure not to lose any of the data stored by your GPS. It extends the use of Prune as a gpsbabel frontend, and of course after it has saved your gpx file it loads it automatically for viewing or editing.
Another new function, to reorganise and sort the photo points within the track. After a correlation operation, it could be that the points which are connected to the photos, are not in time sequence, depending on whether new track points had to be created by the correlation. So this new dialog lets you move all the photo points to either the start or end of the track, and allows you to sort them by either filename (alphabetically) or by timestamp (chronologically). Then when you save just the photo points for example, they'll be saved in the order you want.
The GPX export function now does have the ability to copy the source xml, so even if Prune doesn't recognise or show all the attributes and tags of your GPX (including your own extensions), it will faithfully copy the source xml (if it was loaded from a gpx file, of course) for each point. Unless you've edited the point, in which case the edited values will be output in the same way as before.
Also, you can now select the colour with which the track is shown in KML/KMZ exports, using the same colour chooser as before. And you can save this choice in your settings file (Settings -> Save settings) if you wish.
The menus have undergone a bit of a rethink - the Edit menu was getting far too cumbersome and it was becoming difficult to find functions quickly in there. So the Edit and Select menus have now been split into separate top-level menus for Track, Range and Point. Hopefully this will make functions easier to find. Also, selecting ranges has become easier by using a shift-click on either the map view or the profile view. So in the simplest case you can now click on the start of your range, shift-click on the end of the range, and it will be selected for you. Neat, and much easier than using the toolbar buttons or the menu options. Also you can now see the gradient of the selected range (total altitude difference as a percentage of total distance) in the new "full range details" dialog - this has been split off from the main range details panel along with other details such as pace, to stop the main panel getting too cluttered.
Some work on the photo rotations has also been done, and some strange effects have been discovered (thanks, Thomas!). Firstly, yes it has been confirmed that Prune doesn't use the exif tags for rotation properly, so some photos which should be portrait format are shown in Prune as landscape format. There is usually an option to "fix" the rotation when you import photos from your camera, which is why this problem has gone unnoticed - my portrait photos are displayed and exported fine. Anyway, the first step in fixing this is to add a manual rotation option in Prune, to rotate the current photo left or right by 90 degrees. This is coming in version 9, and obviously your selection is respected for the KMZ export too, however it doesn't modify the photo file itself. Prune now also has automatic recognition of the rotation state using the exif information too, so images should now be displayed and exported correctly, and if not there's the manual rotation. Anyway, a second problem (thanks again, Thomas!) can occur if the thumbnail stored in the exif information doesn't match the image itself. Prune tries to be efficient and only loads the thumbnail if it can find one, which means that if the exif thumbnail is wrong (for example, rotated with respect to the real image, or differently cropped), then Prune will appear to show the image incorrectly. During KMZ export Prune reads the whole image and, as recently discovered, this difference can cause great confusion... Therefore there's now a new option in the "Photo" menu to "ignore exif thumbnail" - if this is selected then the exif thumbnail is not used for preview, but the whole image is loaded instead.
| Language | Completion |
|---|---|
| English, German, Swiss German, Polish, Portuguese, Japanese | 100% |
| French | 99% |
| Spanish | 97% |
| Italian | 90% |
| Chinese | 85% |
| Turkish | 73% |
| Romanian | 32% |
| Afrikaans | 27% |
| Indonesian | 17% |
The translations of Prune are in greatly varying stages of completion. This table on the right summarizes the percentage of translations which are complete for each language, according to the development code.
Also on the right, the right-hand screenshot shows how Prune version 9 looks using the new Japanese translations (thanks again, nazotoko!) - the language pack can be downloaded for version 8, and all the texts are completed for version 9 now too. Make sure your java runtime can find all the required fonts though.
The Turkish translations are now underway thanks to katpatuka - this is looking great so far, as shown in the other screenshot on the right. Almost three quarters of the texts have been translated already, excellent work!
Now is an ideal time to help with the translations if you can - then the texts can be included in version 9 when the testing is finished.
The following credits also appear in the "About" screen of the Prune application, but it's worth repeating here - grateful thanks to all those who have helped contribute so far, by whatever means!
| Prune code written by : | activityworkshop.net |
| Exif code written by : | Drew Noakes (drewnoakes.com) |
| Some icons taken from : | Eclipse |
| Translators : | Ramon (ch), Miguel (es), Inés (es), Piotr (pl), Petrovsk (fr), Josatoc (it), weehal (pl), theYinYeti (fr), Rothermographer (ro), Sam (zh), Rudolph (af), nazotoko (ja), katpatuka (tr) |
| Technical feedback : | Piotr, freegeographytools, Rudolf, Steven, Jose, Jeshi, Denny, Thomas |
| Mac know-how : | Tyme, Daniel, Michael |
| Translations helped by : | Open Office, Gpsdrive, Babelfish, Leo, Launchpad |
| Development tools : | Mandriva Linux, Debian Linux, Sun Java, Eclipse IDE, Svn, Gimp, Inkscape, findbugs |
| Other tools : | Garble, Gpsbabel, Openstreetmap, Povray, Exiftool, Google Earth, Gnuplot |
| Thanks to : | Friends and loved ones, for encouragement and support |
This is more of a longer-term idea, to see if it would be possible to port the Prune code over to a C++/Qt implementation. That way it would be compiled into native, completely free code, and wouldn't need an extra jre to run. Plus the Mandriva team have offered to package it and maintain it in the official Mandriva repositories, making the download and install just a single command. Which would be very cool.
Of course it's still extremely early days on this, and so far there's only a little basic prototype which doesn't actually do anything yet. A laughably simple screenshot is shown here:
All it really demonstrates is the compilation into a GUI application, basic layout including menus and toolbar, and basic internationalization.
As an additional thought, maybe such an effort could use Python and Qt instead of C++ - but then it would just need a python runtime instead of a java one. Obviously such an undertaking would require a lot of effort to rework and redevelop the code and at the moment there's little incentive to start again.