Back in July 1990 I (Olly) was on my first CUCC Austria expedition. We were using some survey software called Surveyor87 - it was pretty good, but the graphics could at best be described as "sluggish" so I sat around in the potato hut at base camp, knocked back a few beers and hacked together a BBC BASIC and ARM assembler cave viewer, which later evolved into caverot.
A decade later, almost to the day, the plan for a new incarnation of Survex began to gel in that same wooden hut. The other main recent contributors to this plan were Mark Shinwell, Phil Underwood, and Wookey. But over the past decade I've been absorbing ideas and suggestions from more people than I can sensibly list here.
After some beer we came up with the name Visual Survex++ 2000 Professional Platinum Millennium Edition. Bleary eyed the next morning Project Spud seemed a better idea (spud being UK slang for Potato).
The project spud plan is to reinterpret the current Survex ethos and reshape the code in line with that in a series of stages. We'll be leveraging our synergies too of course.
Before getting too deep into technical details I'll list some of the major benefits of project spud for the end-user:
A couple of notable problems with the current version are:
I know some will argue for Java rather than C++. But we've had that argument before and it didn't achieve much so I don't want to have it again. But I will point out that we have a lot of C and C++ code we can reuse which we couldn't in Java. And I'll also note that those developers who've expressed an interest so far all favour C++.
Mark Shinwell has devised a plug-in architecture that is simple and lightweight (typically one machine instruction overhead). This will allow other people to write extensions which can be supplied separately (in much the same way that you can download a Macromedia Flash plug-in for your Netscape or Microsoft web browser).
The network reduction code will be reimplemented as a library, which makes it a lot more modular, and potentially allows it to be used in other programs (provided of course that they are released under the GPL).
My plan is to store the survey data in a structured file format (possibly a relational database), with a simple (non-branching) version control system providing a revision history and allowing any previous version of the data to be inspected or processed (very useful for a large survey project lasting many years).
Data in other formats would be converted to this format during processing, so input filters for the native formats of Survex 1, Toporobot, Compass, etc could be written (Survex 1.0 can already read Compass data transparently). Similarly exchange formats such as SEF, CDI, etc could be just read in without an explicit import operation.
This new format would also store a textual representation of the
survey data, which could be used by the GUI data entry editor to
preserve formatting of entered data (so if you enter
The current prefix hierarchy will be replaced with a more structured one - keeping the flexibility where it's actually needed, but tagging levels as "country", "area", "system", "cave", etc.
For ease of coding, we're using the C++ STL. It comes with any ISO conforming C++ compiler - all the compilers which are in active use support it pretty well now. Use of C++ features which are problematic in some implementations can be judged on a cost/benefit basis.
The effort required should be much less than for Survex 1.0. We have a good idea of what we want to achieve as we've already written Survex 1.0. There's plenty of code we can reuse or use for inspiration. Instead of just me coding with some help from Wookey, we're likely to have a handful of developers, and the plug-in architecture should allow us to avoid tripping over each other too much. Survex was my first C program, so a lot of time was initially spent learning C. And lastly C++ is higher level so coding time is more productive.
We believe wxWidgets is the most suitable GUI toolkit for us. It supports Microsoft Windows, macOS, and Unix already. There's also a "universal" port which allows it to run on platforms which provide a framebuffer but have no native GUI (MSDOS is an example). And the really nice thing is that it gives a native look and feel to the application.
Supporting mobile devices like palmtops and smart phones is desirable, but a toolkit isn't enough here I suspect. While the resolution of these devices has increased greatly, they're still small compared to modern desktops, so GUI modules designed for a larger screen size are likely to be less than ideal. The lack of a full keyboard is another issue. Here again, wxWidgets may be a good choice as it is attempting to tackle the issues of targetting such devices.
webmaster: Olly Betts