Project Spud

[Olly Betts]

In message <200008191642.MAA27566@duncan.cs.utk.edu>, David Doolin writes:
>
>>   Whichever approach we take, we're unlikely to have GUI versions for
>>   MS-DOS or RISC OS, but command line versions are still possible.
>
>If the back end is suitably encapsulated, writing a windows gui in either
>win32 or mfc is pretty trivial.

The text you've quoted here makes me wonder if you misunderstood what I
meant here.  By "MS-DOS" I mean *just* MS-DOS, without running MS Windows in
any of its oh so delightful flavours.

You'll be able to run Survex 1.0 on a machine with just MS-DOS, and caverot
will work.  With Survex 2.0 you're unlikely to get full functionality on
such a machine.  But it's a small and diminishing audience, and Survex 1.0
isn't going to stop working just because we're writing a new version.

Out of interest, how many people on this list run Survex on a machine with
just DOS (no MS Windows)?  And how many on a RISC OS machine?

>For a SDI type win32 app, a simple gui
>is about a days work, drawing code a maybe a week or two, and the 
>interface code another week or two.  MFC would be even faster for someone 
>that was very good with it (I am not, yet).  By interface, I mean the 
>appropriate set of callbacks that allow gui independent control.
>Plug-ins are like wise very easy on win32.

True, but writing code is only half the story (actually less than 10% of it
if the studies are to be believed).  Maintenance takes most of the time.

The problem I see writing a separate frontend for each platform is that when
someone writes a plug-in on Unix, it requires effort to port it to MS
Windows, and vice versa.  Also bug fixes typically need to be applied twice,
etc.  It makes it hard to keep the versions on different platforms in sync.

Using a portable toolkit and a portable plug-in architecture means that
theoretically a recompilation is all that is needed to port a plug-in.  In
reality a little adjustment is probably going to be required (even when
they're trying most people don't always write portable code).  But it's much
less than work than rewriting the user interface from MFC to Gtk+ or
whatever.

If this seems a minor concern, look at the number of caverot-like cave
viewers we now have, all with noticably different user interfaces (some
intentionally, but others accidentally).  Here's a list of all the ones I
can remember off the top of my head:

caverot - DOS and RISC OS

xcaverot - Unix with X.  Evolved organically from a quick hack and is now
    hard to maintain.

tunnel - Java, so runs anywhere that has a java runtime environment.  Not
    really a viewer as such, rather a tool for creating 3d models using
    paassage cross-sections.

glcaverot - MS Windows only, uses opengl.  Possibly no longer being
    developed?

aven - uses Gtk-- (Gtk+ with C++ bindings), currently Unix only but MS Windows
    port possible.

chasm - Unix and MSWindows.  Uses Gtk+ (not Gtk--).  Full frontend, not just
    a cave viewer.

potrot - uses Qt and opengl.  Should theoretically be portable to MS
    Windows, but Qt for MS Windows costs $$$.

I've noticed some of the newer ones are now reinventing bugs I fixed in the
original caverot years ago.  For example, during expo we noticed potrot
crashes when fed a survey with no vertical height range (not singling potrot
out, it's just the one I've used most).

Also the mouse controls in xcaverot work backwards from those in caverot,
while potrot has them reversed in one axis (think Mark has fixed this), and
I think Chasm is the same as xcaverot.  As Wookey says, this makes it hard
to move between them.

Caverot is a fairly simple application - this problem is going to be much
worse in a more sophisticated application.

Cheers,
Olly