spud beasts

[Philip Underwood]

On Tue, 10 Oct 2000, you wrote:
> Just my two bits continued because the whole
> discussion is too painful still.  I have three points to
> make and then I'll shut up again.
>
> 1.  File format is ultimately of no relevance.  Everything
> about it is a hinderance.
>
We're really not talking about file formats at the moment. Like you said, its 
fairly irrelevant, but we need to sort something out at some point.
> 2.  The only thing that matters is the user interface.
Depends on how you define user. If you are willing to extend the definition 
of user to someone producing a module to fit into spud, and the interface to 
the sort-of-API they'd have to use, then I'd probably be 
forced to (roughly) agree. Decent speed in doing things would be nice as well. 
Oh, and not crashing a lot.
>
> 3.  The idea that you can design a good working
> interface (or even an entire program for that matter)
> theoretically before you start trying things out is
> pure fantasy.
>
Mmm. And we're not talking about the graphical interface either; we're 
talking about the underlying data model. Which is important if we're going to 
let other people write new modules for spud easily and efficiently. Which is 
why I started off with a suggestion for the data model. Incidentally, this 
discussion is roughly what I had hoped for when I did that. But we do need to 
do a certain amount of planning before starting stuff. Certainly, I've found 
that programs I've properly planned are easier to code, are more reliable, and 
are easier to read.

>
> The improvements and extensions of the Survex format
> don't make it all that new.  I have in my hands readers
> for both the current and my revised format and they are not
> actually very different, Olly.  The improvements are all to do
> with removing commands (rather trivial), and the
> extensions are about introducing new types of objects
> other than legs (such as cross sections and tubes).
> I have demonstrated working examples of these
> features about which you have only talked.  This really
> ought to be worth something regardless of my lack
> of "god-like prescience".
>
> Yes, of course there will always be extensions in
> the future that you haven't thought about.  So what?
> Unless you have an example of at least one
> crucial one to justify a new format, the design
> will wind up directionless and merely be done for the hell of it.
So why not generate a format which is capable of being used by the extending 
module; this happens with HTML - programs which can't display a feature (eg 
bold or italic or stylesheets) can just ignore it. The current survex format 
isn't really that flexible.
>
> Whatever file format you choose you will still have the
> *export/*equate argument, and this piece of theory
> has not been resolved.  It's quite a fundamental component,
> unless you attempt to bury it in a hailstorm of XML sheets.
>
>
> The point about Java is it is extraordinarily good for
> knocking together user interfaces.  It does not require
> a huge amount of expertise in different toolkits and
> fancy languages, and is pretty compact and well documented.
> It is ideal for experimenting with and changing
> possible user interfaces before, if you must, hard
> coding it (casting it into concrete) in experts-only C++ toolkits
> and such like.
I've found that programming with the aid of GLADE (a GUI designer for use 
with GTK) has been very easy - Its very easy to adjust user interfaces 
around, whilst not having to arse about with the actual code for it. In 
chasm, for example, there are relatively few calls to gtk_* functions, outside 
of interface.cpp (which is generated by GLADE anyway). So interface design is 
easy under GTK

>
> It is a demonstrable fact that most programmers
> don't focus as much as they should on user interfaces.
> Once they have been written with all their deficiencies they never
> get changed.  (And who gives a toss if the program's
> commands work very quickly if it is slow and tedious
> work for the human to call up those commands?)
>
> The user interface is often forgotten about for two
> reasons.  Firstly the code has been written in
> an environment which makes it hard to tinker
> about with, so there is not much pleasure in it.
I love playing with my GUI. It's very easy. If we wanted, we could even use 
libglade, which takes its UI from an XML file at run-time (generated by 
glade), so you don't even need to recompile to move the interface about.
> And secondly, programmers find that file formats
> are far more absorbing and interesting even though
> they make no difference to the user whatsoever.
I think that data models are more fun, actually.
>
> That's all for now,
> Julian T.

--
Phil Underwood <furbrain@furbrain.screaming.net>
Fighting disease, illness, and little flaky bits throughout the North West.
--