Prune is available to download from the downloads page, with the latest released version being version 9. Details of the development of version 10 will be given here as it progresses.
Here is a list of enhancements and extra features under discussion for version 10:
metadata-extractor library for exif reading rather than internal one (done)See the wishlist for new features which have been proposed by users of Prune.
Apart from the two bug fixes for version 9 (one involved Prune hanging when altitudes over 1024m were given in the data, and the other involved an incompatibility with java 1.5), the first main progress has been with splitting off the exif-reading calls into a more modular arrangement. This allows Prune now to be packaged in two ways - either with an internal exif library, as it has been done up until now, or just with calls to an external version of metadata-extractor. This was required by the Debian packagers, who want to reduce code duplication and call the other code if possible. So they can package code using the external library and the package manager will pull in the metadata-extractor library as well when you install Prune. There isn't yet a Debian package though, the Debian packagers are currently still working on it.
The second new feature is multiple map layers - maps-for-free.com offer some really nice maps but they're held in multiple layers - the images for showing relief are separate from those showing water features, for example, and they need to be combined to produce a sensible map. Now Prune can do this too, as evidenced by the screenshots on the right. One shows these maps-for-free maps and the other shows two layers from the OSM Reitkarte.
This has now been extended to allow disk caching, and so Prune can use maps either from disk, or from the internet, or both. If offline mode is set, then it only uses the images already on disk; if it's online and disk caching is enabled then it gets any tiles it hasn't got already and saves them in the cache as well. You can now enter multiple custom map sources (using one or two layers) and select one from a list. The next step is to save this list of additional sources in the config and then load them back out again.
| Language | Completion |
|---|---|
| English, German, Swiss German | 100% |
| Polish, Portuguese, Japanese | 98% |
| French | 97% |
| Spanish | 95% |
| Italian | 87% |
| Chinese | 83% |
| Turkish | 72% |
| Romanian | 31% |
| Afrikaans | 29% |
| 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. If you want to help with these translations, just have a look at the translation wiki, you don't even have to register if you don't want to.
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, Jozef |
| 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.