> De gustibus non esse disputandum. What icons and menus would you like me
> to provide you with so that you can use the point-and-click method to
> develop r.binfer scripts? r.combine? How about controlling ps.map? You
> design the user interface, and I'll build it. But not for any Microsoft
> platform. :)

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). 
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).

> 
> > Plenty
> > of available SW for funny low prices allow me to combine those
> > SW packages which are best for solving a specific task.
> 
> 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...

> 
> 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...

> 
> Whom do you mean by "GRASS programmers", and who defines what their "task"
> is? You can only mean (a) GRASS programmers at CERL or (b) GRASS
> programmers outside of CERL. CERL programmers know what their tasks are,
> and they are not bound by what you or I think they are, because they have
> their own clientele (to which neither you nor I belong). GRASS programmers
> outside of CERL are almost always GRASS users who find they need to do
> some programming or shell scripting along the way.
> The number of GRASS
> programmers outside of CERL who are not primarily GRASS users you can
> count on the fingers of one hand. I'm one, some people at Osiris are too,
> and I suspect that Gilles Clement would put himself in that category.
> There are others. But pretty much all other GRASS programmers *outside*
> CERL have user-oriented agendas related to their tasks (or their
> organization's tasks) as GRASS users. So: CERL programmers' tasks are
> defined by somebody other than you or me; other programmers' tasks are
> defined by somebody other than you or me (except that I define my own
> tasks as a GRASS programmer). 

I agree with you. That's why there is a big problem to make GRASS with
floating point or high-technology features (3D and 4D GRASS). 

> 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.

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

Regards,

Jaro

------------------------------------------------------------------------
Jaro Hofierka
Dept. of Cartography, Geoinformatics & Rem. Sensing
Comenius University
842 15 Bratislava          E-mail: hofierka@devin.fns.uniba.sk
Slovakia                           hofierka@geoinfo.fns.uniba.sk
------------------------------------------------------------------------

