GpsPrune is available to download from the downloads page, with the latest released version being version 22.2. Details of the development of forthcoming versions are given here.
Please also look at the user guide for details about the user guide now available (in PDF and EPUB formats) for GpsPrune. Your feedback is valuable and much appreciated.
The following features are on the list for version 23 or later. Please also see the wishlist for new features which have been proposed by users of GpsPrune.
The following is a preview release of version 23 for testing - please be aware that this may well contain bugs of unknown nastiness. If you want to help with testing or with translations, 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 (1.2 MB) |
Version 22.2 is now available in two forms, because it turned out there were runtime issues with Java 8. I thought that compiling with Java 11 with a target of Java 8 would work properly, but it turns out not, so there's now a separate Java 8 jar produced by a Java 8 JDK, which in turn required a handful of minor tweaks.
What will come with version 23 is currently still fairly open, but there is one fairly exciting feature already. The icons in the toolbar are due for an overhaul, and we're taking the opportunity to move to a completely svg-based set of new icons so that they're not fixed to a single resolution. The first step is to make the existing icons more uniform and consistent, as shown in these early screenshots. And yes, the icons aren't as colourful as before but they do have a subtle "prune" hint to them.
Also the waypoint icons will be updated to match. And presumably, sometime later will come some kind of setting to choose which size icons to use, with a choice between these ones (roughly the same size as the current ones) or double sized. In this way, those users with huge screens and tiny pixels can choose to use larger images for the buttons and controls if they wish.
Many thanks to fontawesome.com for the new icons - and for providing them under a CC-BY license! 
There's another series of changes currently underway for version 23, which requires fairly fundamental changes to the invisible mechanisms behind the scenes but so far doesn't add any new features at all. So you could reasonably ask "why bother?". Because there are some invisible benefits on the testing side, making things much easier to test than they were before, so a lot of new tests will be coming shortly. Plus it triggers some cleaning and separating activities which reduce the code and will hopefully make maintenance simpler. And the big reward, right at the very end, will be the addition of a "Redo" button next to the "Undo" button in the toolbar. I know, I know.
Currently a few things are unfortunately broken, but signs point to the end result being of a higher quality than before the breakage. There have been some casualties though — the extension of the "delete fields" function to multiple fields was the first. Never even made it to 22.3 and already it's been deleted from 23, but hey, at least we know it's not heavily used. Maybe it'll come back. "Convert waypoints to timestamps" also got removed, mainly because I haven't used it or wanted to use it for a long time. Another casualty was the "select tracks" dialog which comes up when loading a gpx file containing multiple named tracks. This was originally introduced because it was something I often wanted to do (due to receiver hardware behaviour); I haven't used it for a long time so I'm guessing (hoping) that others don't either.
The next item on the list is a reworking of the texts for the confirm messages and undo descriptions — these probably won't change much in appearance but the way they're generated needs to be adapted. This bit is still ongoing.
Meanwhile.... a kml file provided by a restaurant owner in Germany brought to my attention the possibility that specially crafted links in such kml or gpx files could be misused in the wrong hands. Not that this particular individual was misusing them, but it turned out that a lot of requests were being made without my knowledge. So here is a new confirmation popup coming with version 23, to make sure that you know what you're downloading and that you're agreeing to it. I think that if they're being used legitimately, the linked media (photos and/or audio files) will all come from a small number of domains, and you only have to click 'Allow' or 'Block' once for each domain, so I believe that it's a low overhead for real use cases. The allowed and blocked domains aren't currently stored though, so they're only remembered until you close GpsPrune. As always, feedback on this proposal is welcome.
Another little feature, in the "Point" menu there's now a new "Go to" submenu, with three entries - highest, lowest and fastest (slowest doesn't really make sense I think). Click on one of those, and the corresponding point in the track will be selected for you. This makes it much easier to find that one crazy point with an altitude of -1500m, or that little section of track with crazy high speeds. Or just quickly find the peak of the mountain without hunting through the altitude profile. Obviously if you haven't got speeds or timestamps then you can't select the fastest, and if you haven't got altitudes then you can't select the highest or lowest.
Imagine you've loaded points from several different files, and some waypoints are defined in several of the files. Once you load them all, you've got duplicates of some of your waypoints. It would be nice to remove the duplicates, so that each waypoint only appears once. This sounds straightforward, but it also has to handle the case where one file has the waypoint without an altitude, and another file has it with. Or with an additional comment, or description, or type. In this case it shouldn't necessarily just delete the second instance, because that might have more information than the first. So it's more involved than it at first sounds, but it appears to be done — it's a new function under Track -> Remove duplicate waypoints.
As always, all help with the translations will be very welcome! Please help to expand and improve the coverage of your favourite language. Please see the "translations" section below if you'd like to help.
Since February 2015, GpsPrune has a repository at GitHub. It's got all the history since version 1 in there, and the plan is to keep it updated with the latest released code. For those who find submitting git pull requests easier than submitting diffs by email or sourceforge, then this might be something for you to look at. It's also a good way of raising issues if you have questions or bug reports. I'm guessing that for most people, especially those without github accounts and those unfamiliar with git, the other methods of bug reporting and patch submission will continue to serve well.
Latest status: test jar is available for those keen enough to want to help with testing of version 23, the user guide updates are in progress, and the files for the translators are available on the Translatinator (see below).
| Language | Completion for v21.3 | Completion for 22.2 | Completion for 23 |
|---|---|---|---|
| English, German, Swiss German, Dutch | 100% | 100% | 100% |
| French | 98% | ||
| Spanish, Italian | 97% | 97% | 98% |
| Chinese, Catalan | 100% | 99% | 95% |
| Russian, Hungarian | 97% | 96% | 92% |
| Polish | 94% | ||
| Romanian, Finnish, Swedish | 93% | 92% | 89% |
| Portuguese, Afrikaans, Czech | 89% | 88% | 85% |
| Korean, Japanese | 67% | 66% | 63% |
| Turkish | 43% | 40% | |
| Ukrainian | 27% | 26% | |
| Danish | 22% | 23% | |
| Welsh | 18% | ||
| Norwegian | 13% | ||
| Indonesian, Farsi | < 10% | ||
The translations of GpsPrune are in greatly varying stages of completion. This table on the right summarizes the percentage of translations which are complete for each language. If you want to help with these translations, there are now three (count them, three!) ways for you to do this. The idea is that if the translation process is made as easy as possible for the translator, then the likelihood is higher that somebody might feel like helping out. So to make the entry barrier as low as possible, here are the options, in order of preference:
Obviously it would be great to get the nearly-complete languages back up to 100% again, especially those which were complete for earlier versions of GpsPrune, like for example Catalan, Chinese and Italian.
Unfortunately there are also several languages here less than half-complete, which is why they've not been included in the release jars. You can use these files if you want (available from the download page), but obviously most of the texts are still in English. Any thoughts from users of these languages? Is there any interest in reviving or boosting these translations?
There's an interesting tool called SLOCCount, which goes through a code tree and counts up how many lines of code there are and in which languages. It seems to ignore blank lines, and comment lines and so on, so its figure for GpsPrune is (at the time of writing) 36 thousand lines rather than the 52 thousand which a simple wc -l gives. But anyway, then it uses a formula to estimate how many person-months it would take to develop a traditional commercial product of the same size, and how many dollars you'd have to budget for it (including a bunch of overheads such as project planning and specifications etc). Clearly most of those assumptions and parameters are completely invalid for a small open-source project, but just out of interest, I tried it out. As of version 15, GpsPrune is now worth over 1 meeellion dollars! And for you, it's free :)
The estimator at openhub however comes up with a figure of only around half a million dollars, even using apparently the same parameters, so that might give some indication how meaningful the estimates are! Oddly, this tool completely ignores valuable comments in the code, and valuable text files and properties files, but inconsistently does count an xml file the same as raw code(?) and also cares whether a logical line of code is split into several lines for readability or not. Is a four-line if block really worth so much more (or so much more costly to produce) than exactly the same expression in a one-liner?
Update: there's a bunch more on this topic at development stats, including some pretty charts of GpsPrune's metrics.
There's a very interesting tool called gource (like source but with a g), which makes very pretty animations to visualise a software tree as it grows and develops. Using the logs from the source control repository, it knows the file tree structure, it knows when each file was added, edited or removed, and by whom. And it's able to animate this, with each file represented by a little coloured ball, and each checkin causing balls to appear, move and shuffle around the bouncing tree. Check it out on youtube, it's mesmerizing.
So I tried this little tool out on the GpsPrune tree, and it works great. It shows the bursts of development (new files, often concentrated in single areas, reorganisations of files between directories) between long periods of testing and fixing (mainly edits to files, especially translations and build files). It shows the appearance of new functions like little flowers bursting into bloom, and the gradual transformation from a small bunch of dots into the current package hierarchy, as shown in this screenshot.
The purple dots shown here are the java files, the blue and green dots are the images, there's a bunch of blue translation files, and a small scattering of other file types such as xml and txt.
The following credits also appear in the "About" screen of the GpsPrune application, but it's worth repeating here - grateful thanks to all those who have helped contribute so far, by whatever means!
| GpsPrune code written by : | activityworkshop.net |
| Exif code written by : | Drew Noakes (drewnoakes.com) |
| Many icons provided by : | |
| Services : | SRTM data courtesy of the U.S. Geological Survey |
| Deprecated services : | Maps from |
| 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), Rémi (fr), Marcus (pt), Ali (fa), Javier (es), Jeroen (nl), prot_d (cz), György (hu), HooAU (ko), Sergey (ru), Gilles (fr), serhijdubyk (ua), Péter (hu), Matteo (it), Peter (hu), Oana (ro), Cristian (ro), Roman (ru), Erkki (fi), Paolo (it), Maciej (pl), Erik (sv), Carlos (es), Tche333 (fr), J.M. (ca) |
| Technical feedback and patches : | Piotr, freegeographytools, Rudolf, Steven, Jose, Jeshi, Denny, Thomas, Jozef, Gregor, Robert, Jani, zapfen, Joerg, Alexandre, Anti, José, Arvee, Sebastic, PeHar, fperrin |
| Mac know-how : | Tyme, Daniel, Michael, Richard, Marek |
| Translations helped by : | Open Office, Gpsdrive, Babelfish, Leo, Launchpad, Wiktionary, DeepL |
| Development tools : | GNU/Linux (originally Mandriva, now Debian and Mint), Java (originally Sun, now OpenJDK), an IDE (originally Eclipse, now moving to IDEA), version control (originally Subversion, now git), Gimp, Inkscape, bug-spotting (was findbugs, now IDEA and spotbugs) |
| Other tools : | Garble, GPSBabel, Povray, Exiftool, Google Earth, Gnuplot, JOSM, TeX Live, Sigil |
| Thanks to : | Friends and loved ones, for encouragement and support |
As discussed above, the appearance of the standard java/swing GUI under linux (especially the fonts) is sometimes disappointing. So if the "Nimbus" or "GTK" themes don't please everyone, we could perhaps think of alternatives to java and Swing to present the GpsPrune GUI.
This first idea has been floated for a while now, with the following basic prototype made to demonstrate the basic functionality. It shows the compilation of C++ code into a GUI application, shows the basic layout including menus, toolbar, status bar, the split main screen and various resizing behaviour. It also shows the techniques for internationalization of all the texts using Qt's standard translation mechanism.
This example uses natively-compiled C++, but in theory it could use Python and Qt instead. This has the advantage that the GpsPrune code wouldn't need to be natively compiled separately for each possible platform (of which there are many!) but instead could just be distributed as one single source file. However it would have two disadvantages - it would need a python runtime in order to run, so an additional large dependency for everybody to install, and more importantly it would also rely on the PyQt library to be installed, which adds more fiddling.
In October 2014, a new experiment started to rebuild the main GpsPrune GUI using Java and SWT. The results are shown to the right, laying out the basic GUI elements and getting the resizing to work properly. There's a menu and toolbar, a status bar, and exactly the same multi-language support from the "normal" GpsPrune application rather than a separate Qt technique. This saves translation effort as the identical files can be simply re-used.
This needs some more investigation to see if it's worthwhile, or if the SWT requirements could cause problems for users on the various platforms. But all it needs is a java runtime and the SWT library, both of which are platform-dependent but available for all the major platforms. For the major linux distributions these things are already included.
The current idea is to gradually expand this prototype, gradually taking in more components from the "normal" GpsPrune and seeing what difficulties arise. Apart from simply replicating the existing dialogs and functions, there are two proposed guidelines to shape further improvements. Firstly, each dialog should be able to rebuild itself, so that changing the language will have an instant effect everywhere without requiring a restart. And secondly, the functions which need dialogs should be completely separated from the actual data manipulation that they do - this will make automatic testing easier and will also allow a "Redo" button to be implemented.
Update 2022: OK, so the "current idea" didn't really come to fruition, but the "Redo" function is finally on its way (planned for v23). It's turning into a huge refactoring exercise, but the data manipulation will at the end be separated from the Gui, and the benefits of testing are already apparent. There's still no huge incentive to push for SWT, and no loud calls from users unhappy with the Swing look. Maybe the introduction of the themes has reduced the pressure.
The following jar is for those interested in what this SWT version could look like. It's very basic so far, and doesn't actually do much editing or display of the files. But at least you can see if SWT works on your platform, try out the Help menu and Settings menu, load a kml or gpx file to scroll through the points, see the altitude profile and delete a single point.
|
SWT code for testing (300 kB) |
This seems to be a fairly promising start, with a few things working already, but obviously an enormous amount of functionality still missing. Looking at the time taken to get this far, and the amount of (re)work required to get everything back up to the usefulness of the regular GpsPrune application, it seems like the proposed benefits are perhaps not great enough to justify the effort. Maybe the translation to SWT would be more reasonable if that was the only change required, rather than the restructuring of Functions and TrackOperations being done here, but then the benefit is even smaller, basically just an improved appearance on some platforms. This effort could probably be more usefully applied to enhancing the existing GpsPrune rather than re-doing a lot of the existing work.