[GRASS-dev] New installation for wxPython GUI

[twiens]

----- Original Message Follows -----
From: Glynn Clements <glynn at gclements.plus.com>
To: Trevor Wiens <twiens at interbaun.com>
Cc: Developers List <grass-dev at grass.itc.it>,
grass at 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 at interbaun.com

--
Trevor Wiens
twiens at interbaun.com