[GRASS-dev] New installation for wxPython GUI

GRASS GIS GRASS GIS developer
1

----- Original Message Follows -----
From: Glynn Clements <glynn@gclements.plus.com>
To: Trevor Wiens <twiens@interbaun.com>
Cc: Developers List <grass-dev@grass.itc.it>,
grass@grass.itc.it
Subject: Re: [GRASS-dev] New installation for wxPython GUI
Date: Mon, 14 Aug 2006 09:04:06 +0100

[CC list snipped; anyone who is interested reads one of
these lists.]

Trevor Wiens wrote:

> Sockets are fast and from what I understand are a good
> cross platform solution.

Windows doesn't support Unix-domain sockets (Cygwin
emulates them using TCP sockets). You could either use TCP
sockets (although you would have to implement some form of
access control) or named pipes.

> In this context however the issuing of
> d.* commands would pretty much disappear from CLI use.
> Instead users would do something like "g.ui map1 add
> rast foo", "g.ui map1 redraw", or "g.ui map1 tree" (to
> see the display tree in a simple text representation).

In the "add" case, you may as well just specify the name
of the actual command which will be used to perform the
rendering (e.g. "d.rast") rather than creating a new
GUI-specific layer. IOW, every layer would be a "command"
layer.

I disagree. If we are thinking of rewriting some of these
commands
it makes more sense to me to remove them from use with as
simple a
command line interface as possible that will not need to be
changed
in the future. Thus whatever changes behind the scenes are
implemented
by developers and as little as possible of the user
developed scripts break.
Further, by making every layer a command layer, just means
more redundant
typing and making GRASS CLI use more difficult for newbies.
I don't want to
see GRASS dumbed down, but if I can make it easier to use
with no loss of
control or functionality, why not?

> This could be later expanded to support frames with
> multiple views, etc. This type of interface could be
> used to later generate final output as bits were written
> "g.ui map1 print ps foo.ps" or "g.ui map1 print png
foo.png"

Once you have the ability to control the GUI through
external commands, it's trivial to provide
backward-compatibility by extending the raster library so
that running d.* commands from a shell would signal the
GUI to add a corresponding command layer.

> I want to consider issues related to frames and the
> inserting of text of other graphics in this context as I
> deeply dislike having to fiddle with data in two places
> so would like to see a sufficiently advanced
cartographic system eventually constructed for GRASS that
> use of drawing programs to pretty things up will be a
thing of the past.

I don't think that will ever be the case. There will
always be situations where you want to perform advanced
graphical processing of a kind that is best left to
general-purpose graphics software.

Undoubtedly there will always be exceptions that will
require some
tweaking but for use in production situations, which is my
interest
as I'm not an academic but a consultant, these need to be
exceptions
not the rule (as has been the case for most GIS systems open
or
proprietary).

T
--
Trevor Wiens
twiens@interbaun.com

--
Trevor Wiens
twiens@interbaun.com

2

twiens wrote:

> > In this context however the issuing of
> > d.* commands would pretty much disappear from CLI use.
> > Instead users would do something like "g.ui map1 add
> > rast foo", "g.ui map1 redraw", or "g.ui map1 tree" (to
> > see the display tree in a simple text representation).
>
> In the "add" case, you may as well just specify the name
> of the actual command which will be used to perform the
> rendering (e.g. "d.rast") rather than creating a new
> GUI-specific layer. IOW, every layer would be a "command"
> layer.

I disagree. If we are thinking of rewriting some of these commands
it makes more sense to me to remove them from use with as simple a
command line interface as possible that will not need to be changed
in the future.

Backward compatibility dictates that the core d.* commands have to
continue to work from the command line for a while yet.

Also, as these commands need to remain in order for the GUI to work,
they may as well continue to work as standalone commands.

Thus whatever changes behind the scenes are implemented
by developers and as little as possible of the user developed scripts break.

That's the main point of ensuring that d.* continue to work as
standalone commands.

Further, by making every layer a command layer, just means more redundant
typing and making GRASS CLI use more difficult for newbies.

Why?

I don't want to
see GRASS dumbed down, but if I can make it easier to use with no loss of
control or functionality, why not?

Making d.* stop working is loss of functionality.

--
Glynn Clements <glynn@gclements.plus.com>

3

On Tue, 15 Aug 2006 04:03:17 +0100
Glynn Clements <glynn@gclements.plus.com> wrote:

Glynn,

Perhaps I'm not being clear, thus there are some lengthy comments below
to try to rectify that.

twiens wrote:

> > > In this context however the issuing of
> > > d.* commands would pretty much disappear from CLI use.
> > > Instead users would do something like "g.ui map1 add
> > > rast foo", "g.ui map1 redraw", or "g.ui map1 tree" (to
> > > see the display tree in a simple text representation).
> >
> > In the "add" case, you may as well just specify the name
> > of the actual command which will be used to perform the
> > rendering (e.g. "d.rast") rather than creating a new
> > GUI-specific layer. IOW, every layer would be a "command"
> > layer.
>
> I disagree. If we are thinking of rewriting some of these commands
> it makes more sense to me to remove them from use with as simple a
> command line interface as possible that will not need to be changed
> in the future.

Backward compatibility dictates that the core d.* commands have to
continue to work from the command line for a while yet.

Also, as these commands need to remain in order for the GUI to work,
they may as well continue to work as standalone commands.

> Thus whatever changes behind the scenes are implemented
> by developers and as little as possible of the user developed scripts break.

That's the main point of ensuring that d.* continue to work as
standalone commands.

> Further, by making every layer a command layer, just means more redundant
> typing and making GRASS CLI use more difficult for newbies.

Why?

compare "m.layer add rast foo" with "m.layer add d.rast foo". To a new
user would be unintuitive to add a command inside a command and in my
opinion, OO bad design. This complicates the interaction and serves no
functional purpose. A set of simple to use commands if properly thought
out would not require any change in end use if d.* commands changed or
were eventually removed. Only the development team would need to make
changes to the CLI GUI control commands.

> I don't want to
> see GRASS dumbed down, but if I can make it easier to use with no loss of
> control or functionality, why not?

Making d.* stop working is loss of functionality.

I'm not suggesting that d.* should be removed at this time, but let's
face it, individual d.rast, d.vect, etc use is a pretty clunky way of
drawing a map. Adding layers and issuing a draw or zoom, etc. command
is much more elegant and intuitive. I don't see what functionality is
lost in doing so. Further, as d.* commands don't lend themselves, IMO,
to building a proper cartographic interface which needs to have as the
root, a page (which could be either a screen display or a printed page
size) containing frames which in turn could contain maps, text or
external graphics. I realize that GRASS is an analysis oriented system
but there is no reason (other than manpower limitations) why it
couldn't have a decent cartographic interface that was just part of the
ordinary use of the system so after viewing, printing would be
straightforward and would require no extra tweaking in most cases. As
you pointed out earlier, there are always cases which require special
tweaking, but I reiterate that this should be the exception not the
rule.

My personal interest and involvement is to make GRASS more elegant to
use. In my opinion GRASS is not lacking in power, but the learning
curve is steep and it is not elegant to use. Specifically having a
decent scripting environment (eventually dumping bash dependency
because as you've pointed out on numerous occasions bash sucks but
designing the new gui/cli interface so that users who like bash can
continue to use it for the foreseeable future); integrating the GUI and
the shell so that the transition from newbie to poweruser is quicker
and more natural (in this case allowing full GUI control from CLI and
building the new GUI to help users learn simple scripting through
ordinary use); and third to improve cartographic control so that one
can generate publication quality output without a lot easily. Which in
my mind would be providing at least as good output as GMT (which IMO
sucks, but is the best free game in town right now).

In my mind to meet these goals, a better set of CLI commands are needed
that use the current back end commands (d.*), but would eventually
replace the use of the d.* commands not because the old commands didn't
work any more, but because the new interface would be more elegant and
quicker to use.

Perhaps that is clearer both where I'm coming from and what I want to
do.

T
--
Trevor Wiens
twiens@interbaun.com

The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)

4

Trevor Wiens wrote:

> > Further, by making every layer a command layer, just means more redundant
> > typing and making GRASS CLI use more difficult for newbies.
>
> Why?

compare "m.layer add rast foo" with "m.layer add d.rast foo". To a new
user would be unintuitive to add a command inside a command and in my
opinion, OO bad design. This complicates the interaction and serves no
functional purpose. A set of simple to use commands if properly thought
out would not require any change in end use if d.* commands changed or
were eventually removed. Only the development team would need to make
changes to the CLI GUI control commands.

Apart from possibly eliminating the need to type the "d.", I don't
really see much point in writing wrappers for all of the d.* commands.

The GUI commands will inevitably mirror the d.* commands to some
extent, as those are the only mechanism through which the GUI can
display anything.

Any feature provided by the GUI will need to be based upon a d.*
command, and any d.* command should be available through the GUI.

And, unless you manage to abstract the d.* layer away perfectly (which
is likely to be harder than it seems), users will need to learn two
sets of commands.

IMHO, it would make more sense (and reduce code bloat) if a GUI layer
was simply an arbitrary d.* command. At least, any other approach
would appear to require justification as to its benefits.

> > I don't want to
> > see GRASS dumbed down, but if I can make it easier to use with no loss of
> > control or functionality, why not?
>
> Making d.* stop working is loss of functionality.

I'm not suggesting that d.* should be removed at this time, but let's
face it, individual d.rast, d.vect, etc use is a pretty clunky way of
drawing a map. Adding layers and issuing a draw or zoom, etc. command
is much more elegant and intuitive. I don't see what functionality is
lost in doing so. Further, as d.* commands don't lend themselves, IMO,
to building a proper cartographic interface which needs to have as the
root, a page (which could be either a screen display or a printed page
size) containing frames which in turn could contain maps, text or
external graphics. I realize that GRASS is an analysis oriented system
but there is no reason (other than manpower limitations) why it
couldn't have a decent cartographic interface that was just part of the
ordinary use of the system so after viewing, printing would be
straightforward and would require no extra tweaking in most cases. As
you pointed out earlier, there are always cases which require special
tweaking, but I reiterate that this should be the exception not the
rule.

Regardless as to the merits of a GUI, the need to be able to perform
all tasks (including viewing maps) from a shell remains. In order to
be able to remove the existing monitors, it is necessary to have a
suitable replacement, which means the ability to use the GUI as
nothing more than a monitor.

My personal interest and involvement is to make GRASS more elegant to
use. In my opinion GRASS is not lacking in power, but the learning
curve is steep and it is not elegant to use. Specifically having a
decent scripting environment (eventually dumping bash dependency
because as you've pointed out on numerous occasions bash sucks but
designing the new gui/cli interface so that users who like bash can
continue to use it for the foreseeable future); integrating the GUI and
the shell so that the transition from newbie to poweruser is quicker
and more natural (in this case allowing full GUI control from CLI and
building the new GUI to help users learn simple scripting through
ordinary use); and third to improve cartographic control so that one
can generate publication quality output without a lot easily. Which in
my mind would be providing at least as good output as GMT (which IMO
sucks, but is the best free game in town right now).

bash sucks as a programming language. It's a perfectly good
interactive shell, and will remain the primary interface to GRASS for
a signficant proportion of its user base.

--
Glynn Clements <glynn@gclements.plus.com>

5

See comments below.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

....lots snipped...

Why?

compare "m.layer add rast foo" with "m.layer add d.rast foo". To a new
user would be unintuitive to add a command inside a command and in my
opinion, OO bad design. This complicates the interaction and serves no
functional purpose. A set of simple to use commands if properly thought
out would not require any change in end use if d.* commands changed or
were eventually removed. Only the development team would need to make
changes to the CLI GUI control commands.

Keep in mind that after a "m.layer add rast foo" you need to add the
arguments that tell m.layer how to composite and display foo. For some
layers (e.g., vectors, legends) there are a lot of arguments. Do you plan to
have new versions of these too? This is a lot of work. If the CLI could
simple recognize existing GRASS commands, it would save a lot of coding.

I don't want to
see GRASS dumbed down, but if I can make it easier to use with no loss of
control or functionality, why not?

Making d.* stop working is loss of functionality.

A cartographic module would be welcomed by many (though my experience with
commercial products keeps me skeptical about its real utility). To me, page
layout works better if it is wrapped in a GUI (even if you can specify
individual item properties like size, fonts, kerning, etc.). That's why most
of the world uses programs like PageMaker instead of LaTex. However, this is
a lot of work to code too.

It sounds like you are proposing more of a CLI-based cartography module
(conceptually along the lines of LaTex perhaps?). If so, why not work with
improving the existing CLI cartographic module, ps.map? Make it easier to
use so that it can be realistically be controlled interactively from the
CLI. Just a thought.

I'm not suggesting that d.* should be removed at this time, but let's
face it, individual d.rast, d.vect, etc use is a pretty clunky way of
drawing a map. Adding layers and issuing a draw or zoom, etc. command
is much more elegant and intuitive. I don't see what functionality is
lost in doing so. Further, as d.* commands don't lend themselves, IMO,
to building a proper cartographic interface which needs to have as the
root, a page (which could be either a screen display or a printed page
size) containing frames which in turn could contain maps, text or
external graphics. I realize that GRASS is an analysis oriented system
but there is no reason (other than manpower limitations) why it
couldn't have a decent cartographic interface that was just part of the
ordinary use of the system so after viewing, printing would be
straightforward and would require no extra tweaking in most cases. As
you pointed out earlier, there are always cases which require special
tweaking, but I reiterate that this should be the exception not the
rule.

My personal interest and involvement is to make GRASS more elegant to
use. In my opinion GRASS is not lacking in power, but the learning
curve is steep and it is not elegant to use. Specifically having a
decent scripting environment (eventually dumping bash dependency
because as you've pointed out on numerous occasions bash sucks but
designing the new gui/cli interface so that users who like bash can
continue to use it for the foreseeable future); integrating the GUI and
the shell so that the transition from newbie to poweruser is quicker
and more natural (in this case allowing full GUI control from CLI and
building the new GUI to help users learn simple scripting through
ordinary use); and third to improve cartographic control so that one
can generate publication quality output without a lot easily. Which in
my mind would be providing at least as good output as GMT (which IMO
sucks, but is the best free game in town right now).

In my mind to meet these goals, a better set of CLI commands are needed
that use the current back end commands (d.*), but would eventually
replace the use of the d.* commands not because the old commands didn't
work any more, but because the new interface would be more elegant and
quicker to use.

Perhaps that is clearer both where I'm coming from and what I want to
do.

T
--
Trevor Wiens
twiens@interbaun.com

The significant problems that we face cannot be solved at the same
level of thinking we were at when we created them.
(Albert Einstein)