[GRASS-dev] Re: 'g.gui wxpython' won't work in wingrass as wxgui is a shell scrip

[Michael Barton]

On Mar 19, 2008, at 7:11 PM, grass-dev-request at lists.osgeo.org wrote:

> Date: Wed, 19 Mar 2008 23:10:29 +0600
> From: Ivan Shmakov <ivan at theory.asu.ru>
> Subject: [GRASS-dev] Re: 'g.gui wxpython' won't work in wingrass as
> 	wxgui	is	a shell script
> To: grass-dev at lists.osgeo.org
> Cc: Ivan Shmakov <oneingray at gmail.com>
> Message-ID: <m2lk4efxmi.fsf at cherry.siamics.int>
> Content-Type: text/plain; charset=us-ascii
>
>>>>>> Michael Barton <michael.barton at asu.edu> writes:
>
>>>> Not really. Simple tasks can be done with just the GUI.
>
>>> One certainly won't go far only doing simple tasks.

First a context statement that may seem a bit odd given my comments  
below. I strongly encourage social and natural scientists to be able  
to think about processes in algorithmic terms -- "computational  
thinking" in current NSF jargon -- and I have several large projects  
in the works to develope ways to encourage this broadly in the  
sciences. I also program, although completely self taught with all of  
its pitfalls, and encourage my students to learn programming skills  
as needed.

>
>> Actually you can do some pretty complex stuff with the GUI. Try it.
>
> 	Actually I've meant the ``... but it might take you a LOT
> 	longer...'' cases specifically here.
>
> 	Nowadays, it seems that even computer programmers, let alone
> 	users, have very little experience with programming [1].

Agreed. In many cases it is simply unnecessary. I think that it is a  
good idea to know how an automobile works and be able to do some  
level of repairs or maintenance on it. BUT for many people, this is a  
waste of very precious time and unnecessary in order to drive the car  
from point A to point B. When I was a graduate student, one had to  
learn to program to get any use out of a computer. Now you can do an  
enormous amount of useful work without knowing a bit of programming.  
I think this is great. Nothing wrong with programming. But why MUST  
one learn it when it is not necessary to use the computer as a tool?

> 	Consequently, even a simple ``show me a MODIS Total Totals index
> 	on a map'' task becomes unsolvable by adding a ``... for every
> 	day of july, 2007'' bit to it.

Yes, this is a task that programming would help with. But it is a  
task that the great majority of computer users never need to do.

>
> [1] http://www.stsc.hill.af.mil/CrossTalk/ 
> 2008/01/0801DewarSchonberg.html
>
> 	Perhaps, my perception is influenced quite heavily by my
> 	experience with remote sensing (and to have 100 rasters per day
> 	for a monthly interval is hardly an untypical situation.)  But I
> 	really believe that an ``average computer user'' is expected to
> 	know at least a couple of programming languages.

This doesn't match with your statement above. In fact, I'd wager that  
the average computer today user knows absolutely NO computer language  
at all. People have a lot to do in limited time. Learning and using  
programming languages requires a significant investment of time. Why  
should they learn 2 or more computer languages when it is of no use  
to getting their work done? Why would any employer want their  
employee to do so when it is unnecessary to use a computer?


>
> 	Unfortunately, typical GUI cannot be easily programmed and thus
> 	(as it seems to me) discourages programming way too often.
> 	(Though the GRASS GUI seems to be on the right way to overcome
> 	this problem.)

So we should make applications more difficult to use so that users  
are forced to get the character-building experience of learning to  
program? That doesn't seem to be a good way to make analytical tools  
available to users who need them. That seems a way to make sure that  
only a very limited group of specialists can use computational tools.  
Is that what we want?

People should learn programming if it helps them solve problems.  
There is no reason except the history of computation why  
computational devices should be controlled by typing English words on  
a screen in a particular syntax. Furthermore, typing words is not the  
not a particularly "normal" way for humans to manipulate  
representations of spatial relationships. We are much more accustomed  
to represent spatial relationships through gestures, for example.


>
>>>> More complex tasks really deserve a proper programming  
>>>> language.  The
>>>> range inbetween, where bash is a reasonable solution, is actually
>>>> quite narrow.
>
>>> The only thing that I have to say in the defense of Bash is that
>>> the little languages always have a narrow, but not a negligible
>>> niche.
>
>> The thing that bash allows you to do is to chain together the same
>> commands that you get in the GUI. That is, you can do the same stuff
>> in the GUI that you can do by scripting, but it might take you a LOT
>> longer to accomplish it.
>
> 	Well, yes, but would one's actions be accurate after doing the
> 	same for 10 times? or 100 times? or 1000?
>
> 	Apart from the obvious unreliability of a tired user, any real
> 	life task has its time constraints.

I agree absolutely. This is the advantage of being able to script  
GRASS if you need and want to do it. A GUI has its place and so does  
combining operations to automate a series of repetitive, error-prone  
tasks. This is why GRASS definitely needs to remain completely  
scriptable. But this is not an either or with GUI use. One should not  
be forced or encouraged to use either method to access commands.

In fact, I'd love to see the addition of other ways to manipulate the  
tools that make up GRASS. For example, a year ago, I saw a demo of a  
great visual environment for creating GIS models by combining  
commands. Some command objects could be nested inside other command  
objects or linked to command objects through graphic representations.  
OSSIM does something along this line.

I personally might prefer to type some stuff--because I'm used to it-- 
but this could be a very powerful way to apply algorithmic thinking  
to the creation of multi-process, interative geospatial models.

>
>> Any scripting language that can interact with GRASS commands (i.e.,
>> most of them) can serve this same purpose. You can do it with Python,
>> PERL, Java, TclTk, etc. Bash is handy because it comes preinstalled
>> on Linux and Mac systems (and sh on earlier Unix systems) and was
>> consistently available even when other scripting languages were not.
>> It is only for this historical reason that it has become a standard
>> for scripting in GRASS.
>
> 	Yes.
>
>> IMHO, it's a pretty primitive and opaque programming language (e.g.,
>> you have to use another scripting language like awk to do floating
>> point math).
>
> 	That's quite a frequent practice (consider, e. g., `expr' in
> 	Tcl, or Cpp for C.)  I don't think it should be afraid of.

expr does not call another language in TclTk, it simply signals to  
evaluate an expression--any experession.


>
>> You can do a lot with it, but it is not easy to do or to deconstruct
>> (or debug) what others have done. I say this in spite of having made
>> a number of the existing GRASS Bash scripts, including some pretty
>> complex ones (e.g., d.vect.thematic).
>
> 	Real programmers can write Shell in any language, I guess.
>
> 	To put it serious, it seems to me that the potential of the
> 	Shell wasn't fully exploited.  (After all, where's that library
> 	of the Shell functions deemed useful for a GRASS programmer?)
>
>> With GRASS 7 and opening up of GRASS for Windows, we have an
>> opportunity to modernize scripting on GRASS (Note I am not a Windows
>> user). There will always be people who script in Bash. It's great
>> that one can do so.
>
> 	Yes, it certainly makes sense to support many different
> 	languages available for GRASS scripting.
>
>> However, I think that it would benefit the community settle on a new
>> scripting "standard" that is truly cross- platform and an easier,
>> more up-to-date, powerful, and easier to use language. There are
>> several good candidates for this, but Python has a number of
>> pragmatic advantages in the current context.
>
> 	Indeed, it may be a reasonable decision.  (Though it'd be
> 	interesting for me to know what are the particular problems with
> 	Tcl, which is both portable and was used in GRASS for quite some
> 	time?)

TclTk is a nice GUI platform, but there are some limitations  
especially with the creation of graphic canvases. We went through  
them in detail a couple years back. It's on the WIKI I think. If not,  
I think I've got copies of the discussions and can send them to you.  
It also turns out that TclTk for Mac has problems, which is why GRASS  
for Mac is distributed with X11 TclTk instead of the aqua version-- 
though maybe these are getting fixed with 8.5 and above.

However, beyond a platform for GUI development, Python (i.e., not  
wxPython) is more full-featured as a general purpose programming  
language. It is also a lot easier to use than bash. And this will  
hopefully will encourage more people to try their hands at  
programming tasks in GRASS. I don't want to make programming a  
requirement, but I DO want to make it easier for users to create  
programs to solve problems with GRASS when they need to do so. And I  
DO want to encourage social and natural scientists to conceptualize  
system dynamics in algorithmic ways. This is easier done if people  
have some programming experience.


>
>> What this means is that we need to have Python people volunteer to
>> begin to rewrite existing Bash scripts in Python and begin writing
>> any new scripts in that platform so that we can have the critical
>> mass to encourage others to learn it and write in it. A couple people
>> have started on this.
>
> 	I'm afraid that an attempt to rewrite /all/ the Shell scripts in
> 	Python will both take time and bring some mess along.  Would
> 	you, e. g., consider an untested 100-lines Python substitute for
> 	a 50-lines Shell script (that's known to be working for years)
> 	to encourage anyone to write in Python?

Actually, from my limited experience, I'd suspect that it would be  
the other way around--50 lines of code or less in Python to replace  
100 lines of bash shell script, and be easier to read.

The shell scripts distributed with GRASS are an integral part of the  
distribution package. To the average user, they are functionally  
equivalent to the modules programmed in C. We need to replace shell  
scripts with the same functions in a portable cross-platform language  
if we want GRASS to work well on non-POSIX systems (primarily  
Windows). IMHO, it would be (and is) problematic to continue to  
release GRASS with a significant number of critical modules that fail  
on a very common OS. There really aren't all that many that would  
need to be replaced. Some of them might well even work better if re- 
written.


>
> 	If there're particular strong points of Python, they're to be
> 	exploited first (is wxPython among the others?)
>

Python is the general purpose object-oriented programming language.  
wxPython is a Python port of the wxWidgets GUI interface development  
platform. You can do all scripting of GRASS in Python without  
employing wxPython at all. However, Python is needed in order to use  
wxPython for GUI development.

Michael