multi-g.manuals; concurrency locking

[Mark P. Line]

On Sat, 26 Mar 1994, Jaro Hofierka wrote:

> Icons or menus  are for controlling programs like r.binfer, r.combine
> or something like ps.map (which is useless under MS Windows as
> your finished WYSIWYG map or picture is sent directly to the 
> postscript printer or to the *.ps file using the point-and-click method). 

How would you use icons or menus to control r.binfer, for example? I think
we're misunderstanding each other here.

> Besides this, all of these
> programs have been programed in C-language and I do not see
> a big problem to move them under MS Windows. For example
> all the programs I was working on had been programmed 
> on a PC using Borland C++ with elegant Development Environment
> which drastically reduces development time (e.g. r.flow, r.flow.3d,
> r.flow.time, r.sun) and only after that I moved them into GRASS
> (it usually took me a few days).

I suspect that the code in r.flow, r.sun etc. was pretty
platform-independent (largely numerical, aren't they?). What about
developing the equivalents to xgdisplay, xgregion, xgmapcalc or xdigit
under MS-Windows? And to what end?

> > Precisely. Linux, XFree, GRASS, Khoros, Tcl/Tk, ...
> > 
> These are really low-cost but also with minimal guarantees and
> low technical support and documentation. I do not prefer hunting bugs...

Low documentation only applies to GRASS, out of the packages I mentioned
above. Low technical support only applies to any of them if you don't have
access to the Internet. If you do, then there are hundreds (for Linux:
tens of thousands) of people who read the newsgroups where you can get
tech support.

I've been using the above configuration (except for Khoros, which breaks
my disk space for the time being) for over six months now, and have yet to
hunt for any kind of bug. I just install the software and use it. I think
you might have gained a very wrong impression of contemporary freeware.

> > User interfaces to software have to match the "bandwidth" of the software
> > being controlled. Point-and-click-type interfaces have a very low
> > bandwidth, which is fine if that's what your underlying software has. Some
> > parts of GRASS have such low bandwidth: d.rast, d.erase, d.frame if you
> > break it down into component actions, etc. Other parts of GRASS, however,
> > have a *very* much greater bandwidth: r.[b]infer, r.combine, p.map and so
> > on. Trying to force high-bandwidth software under a low-bandwidth user
> > interface will only cause problems.
> 
> Ask Intergraph, PCI and other companies why they move their products 
> under Windows NT...

Ask them why they're simultaneously retaining support of their traditional
Unix platforms. Vendors will port software if there are customers for
the new platform. There are customers for new Microsoft platforms because
Microsoft has a good marketing department.

Anyway, GRASS is being ported to Windows NT also. Why not? NT has a
Unix-like kernel derived from Mach. If the system dependencies can be
worked out for the display subsystem, then there's no reason why GRASS
shouldn't be ported to NT. You can bet, though, that that most definitely
will not cause GRASS to disappear from Sun, SGI or Linux platforms.

> > I think you're forgetting where GRASS is coming from (literally) and how
> > it is developed. If you do not want to do your own GRASS programming, but
> > have good suggestions on how you think GRASS could be improved, you should
> > definitely post your ideas to one of the GRASSHopper lists. Maybe somebody
> > will take you up on your ideas. If you keep them to yourself, they can't.
> 
> You are also saying: if you do not satisfied then make your own
> program or wait 5-10 years when someone will make it.

Come on, Jaro, play fair. As you can see, I explicitly said the *opposite*
of what you're accusing me of here. What would the people who develop and
maintain Windows NT say if you told them you thought it needed a
left-handed gribbet? They would say, "if you are not satisfied then make
your own program or wait 5-10 years and someone will make it". What do the
many GRASS programmers say when you tell them that GRASS needs a
left-handed gribbet? Well, I can't speak for others, but I always say,
"tell me how you think a left-handed gribbet should work in GRASS, and
maybe I can make one, if I think I and other people might need one, too".
That is, in fact, what happens constantly within the GRASS community.
You've done so yourself, in fact, haven't you?

> Do you think this is the best way how to hold GRASS among top GIS'?

Funny you should mention that. GRASS probably has the worst user interface
of any GIS I've ever seen, but its strict modularity makes it pretty easy
to shrink-fit just about any user interface front-end around an existing
installation. Nobody in her right mind would ever claim that GRASS was
easy to learn, but it's not really hard to use. Nevertheless, there are
something like 15,000 GRASS users worldwide, from what I hear. One reason
for that might be that it doesn't cost anything. But, there's lots of free
software that people won't use, for various reasons. So there must be
additional reasons why so many people want to use GRASS, in spite of
itself. 

Jaro, nobody is telling you to "go write a program if you don't like what
you've got", because nobody is telling you to use GRASS, and the GRASS
you've got probably didn't cost you much.

So, now, I'm ready to hear all your constructive comments on what aspects
of GRASS should be improved. And I'm not telling you to go off and worry
about the improvements yourself, but I'm offering to look into the
possibilities of contributing code or documentation. That is, unless you
don't want me to.

-- Mark

--------------------------------------------------------------------
Mark P. Line                       Phone: +1-206-733-6040
Open Pathways                        Fax: +1-206-733-6040
P.O. Box F                         Email: markline at henson.cc.wwu.edu
Bellingham, WA 98227-0296
--------------------------------------------------------------------