[GRASS5] GRASS GUI

GRASS GRASS developer
,
1

Hi everyone,

Looks like the talk on the right GUI for GRASS is getting a little
warmer... While QGIS is a very good GIS application supporting GRASS I
think that what Michael, Martin and myself are exchanging thoughts about
now is where GRASS's *own* display abilities are headed.

As GRASS moves to version 7, it is only natural that the display module
of GRASS is part of that process. In my opinion the d.* modules and
especially the interface to them do not reflect current GUI abilities.

So let's keep pondering where me might head with that. If we in the end
start work on our own GUI for GRASS is not yet said though some might
think that this is neccessary (that includes me).

Crischan

2

Christian Wygoda wrote:

Hi everyone,

Looks like the talk on the right GUI for GRASS is getting a little
warmer... While QGIS is a very good GIS application supporting GRASS I
think that what Michael, Martin and myself are exchanging thoughts about
now is where GRASS's *own* display abilities are headed.

Just to add my 2 cents: The survey done last year[1], showed a clear majority of users in support of a native GRASS GUI.

One argument (even though this is less important for those GRASS users who have access to modern machines, i.e. most of the developers) is size: in Debian the grass + libgrass packages have an installed size of 14564 + 2100 KB, whereas QGIS needs 21588...

So, in my eyes any new GRASS GUI should remain lightweight...

Another criteria for me would be ease of modification. I really like the fact that currently anyone can follow simple instructions on how to modify one text file to see a new command added to their GUI. People might not want to have to recompile everytime they wish to add a new command.
Something in the line of what Radim has done for the QGIS-GRASS bridge might be another solution.

Moritz

[1] See GRASS newsletter 2, http://grass.itc.it/newsletter/index.php

3

At 14:47, lunedì 14 novembre 2005, Moritz Lennert has probably written:

Just to add my 2 cents: The survey done last year[1], showed a clear
majority of users in support of a native GRASS GUI.

but:
1. last year the potential of qgis+grass was far from being clear to the vast
majority of users
2. the report identifies the look&feel of tcltk as"repelling" for new users
(the most important category for our community, in my view)
3. the report identifies the cluttering of windows as a problem
4. zooming and panning are far more intuitive in qgis that in tcltkgrass

One argument (even though this is less important for those GRASS users
who have access to modern machines, i.e. most of the developers) is
size: in Debian the grass + libgrass packages have an installed size of
14564 + 2100 KB, whereas QGIS needs 21588...

So, in my eyes any new GRASS GUI should remain lightweight...

I do not agree with this. Nowadays even entry level PCs have a power that make
this cosiderations irrelevant in the majority of applications.

Another criteria for me would be ease of modification. I really like the
fact that currently anyone can follow simple instructions on how to
modify one text file to see a new command added to their GUI. People
might not want to have to recompile everytime they wish to add a new
command.
Something in the line of what Radim has done for the QGIS-GRASS bridge
might be another solution.

to include new modules in the menus is really easy (it requires the
compilation, though)
pc

Moritz

[1] See GRASS newsletter 2, http://grass.itc.it/newsletter/index.php

--
Paolo Cavallini
email+jabber: cavallini@faunalia.it
www.faunalia.it
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953

4

Paolo Cavallini wrote:

At 14:47, lunedì 14 novembre 2005, Moritz Lennert has probably written:

Just to add my 2 cents: The survey done last year[1], showed a clear
majority of users in support of a native GRASS GUI.

but:
1. last year the potential of qgis+grass was far from being clear to the vast majority of users
2. the report identifies the look&feel of tcltk as"repelling" for new users (the most important category for our community, in my view)
3. the report identifies the cluttering of windows as a problem
4. zooming and panning are far more intuitive in qgis that in tcltkgrass

Except for point 1, I don't understand what the rest has to do with the
question of whether grass should have a native GUI...

One argument (even though this is less important for those GRASS users
who have access to modern machines, i.e. most of the developers) is
size: in Debian the grass + libgrass packages have an installed size of
14564 + 2100 KB, whereas QGIS needs 21588...

So, in my eyes any new GRASS GUI should remain lightweight...

I do not agree with this. Nowadays even entry level PCs have a power that make this cosiderations irrelevant in the majority of applications.

But it's not only about the machines, but also about network connections...
And for many people around the globe, entry-level PCs are not what we
think of them in rich countries.

Another criteria for me would be ease of modification. I really like the
fact that currently anyone can follow simple instructions on how to
modify one text file to see a new command added to their GUI. People
might not want to have to recompile everytime they wish to add a new
command.
Something in the line of what Radim has done for the QGIS-GRASS bridge
might be another solution.

to include new modules in the menus is really easy (it requires the compilation, though)

If you are speaking of QGIS, I thought you just needed to edit an xml
file without any need for recompilation ?

Moritz

5

Hello all,
  I am using GRASS for some time, for both GIS
applications and Image processing. We tried to spread
the use of GRASS in my institute and lack of good GUI
is the first complaint any new user raises. So I wish
to drop my ideas. (Sorry for a long mail........)

Single Window/ Multiwindow
-------------------------------------------
  For GIS applications an integrated single window
application is better. I like thuban, QGis for simple
operations. But for Image processing applications a single
window is not sufficient at all. But in GRASS when I open
multiple display windows, my desktop become cluttered!.

       So I think a "tabbed" approach(like in gedit, firefox etc)
may be better. Each display window should be a "tab" and each
tabs should be "docable".

Tool kit(TK/GTK/QT)
-----------------------------
  Custom application development is very important in
GIS. Hence selection of toolkit decides the way in which
we can develop custom applications based on GRASS. Now each
programmer has his own choice for toolkit. I like Gnome(and uses Gtk),
and similarly someone else may like KDE(and use QT).
  So first a generic outline need to be developed. Later
it should be implemented in both Qt and Gtk(atleast). So we
can have a base application(say grass) and a set of GUI's
(ggrass,kgrass,wxgrass etc). Initially it can be implemented
in one toolkit and later extend to all.

Layers
-----------
  "thuban" has good support for layer concept. But GRASS needs
additional features like "swipe" feature in ERDAS. Also we should be
able to assign transparency to layers. "Legend" editing should be
easy at display level. (as in thuban?).

Bye

--
Change the rules, or the rules will change you
     ---------Kumaranasan

6

I think the GUI toolkit should run *natively* cross-platform.

GTK: X11. That is, on Mac OS X is requires the X11 environment. I saw the beginnings of a native Mac port, but it could take a while. I'm not sure how it works on Windows, cygwin? I think I saw a well developed native port.

Tcl/Tk: X11. There are native builds of this on Mac and Windows. But, when I tried to use that on Mac OS X I ran into conflicts between X11 stuff and Mac OS X. GRASS would have to be completely divorced from X11.

Qt: native from the ground up. I just started playing with qgis. From the binaries, it's a Mac application (or Windows, or X11), though the GUI widgets are a lot like Windows. I'm trying a build from source (so I can update GDAL in it) and maybe there are some settings to use some more native versions of things (like the open/save dialogs).

As for a choice of GUI kits, I wonder if would be possible to abstract the GUI functions in a GRASS library, and that will use whichever GUI kit was built into that copy of GRASS. It might even then be possible to plug binaries of the GRASS GUI library into a GRASS binary to switch between GUIs. Maybe start with Qt and add others later. Just a thought.

On Nov 14, 2005, at 11:33 PM, Sajith VK wrote:

Tool kit(TK/GTK/QT)
-----------------------------
  Custom application development is very important in
GIS. Hence selection of toolkit decides the way in which
we can develop custom applications based on GRASS. Now each
programmer has his own choice for toolkit. I like Gnome(and uses Gtk),
and similarly someone else may like KDE(and use QT).
  So first a generic outline need to be developed. Later
it should be implemented in both Qt and Gtk(atleast). So we
can have a base application(say grass) and a set of GUI's
(ggrass,kgrass,wxgrass etc). Initially it can be implemented
in one toolkit and later extend to all.

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

"History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history."

- Hitchhiker's Guide to the Galaxy

7

Hi,

IMHO grass should be kept as professional tool. For creating simple
printable maps etc. there are many other tools (QGIS ie.). IMHO GRASS
should be "working horse" that does all hard job and not tries to sit
on 2 chairs.

Using multiple GUI tool kits is wrong, as there are many toolkit
specific problems and using time for duplicating work is bad idea, as
we do not have as many GRASS developers to do so. Better write new
tools on enhance existing ones than shiny new GUI without content.

As most of this lists users use GRASS, they have no clue how
commercial products work. WTF is swipe in ERDAS? And WTF is ERDAS?
ViewFinder, Imagine?

OFT: Has anyone of You used SAGA (2.x)? If no - give it a try.

Just my 2c.
wbr,
Maris.

2005/11/15, Sajith VK <sajithvk@gmail.com>:

Hello all,
        I am using GRASS for some time, for both GIS
applications and Image processing. We tried to spread
the use of GRASS in my institute and lack of good GUI
is the first complaint any new user raises. So I wish
to drop my ideas. (Sorry for a long mail........)

Single Window/ Multiwindow
-------------------------------------------
        For GIS applications an integrated single window
application is better. I like thuban, QGis for simple
operations. But for Image processing applications a single
window is not sufficient at all. But in GRASS when I open
multiple display windows, my desktop become cluttered!.

       So I think a "tabbed" approach(like in gedit, firefox etc)
may be better. Each display window should be a "tab" and each
tabs should be "docable".

Tool kit(TK/GTK/QT)
-----------------------------
        Custom application development is very important in
GIS. Hence selection of toolkit decides the way in which
we can develop custom applications based on GRASS. Now each
programmer has his own choice for toolkit. I like Gnome(and uses Gtk),
and similarly someone else may like KDE(and use QT).
        So first a generic outline need to be developed. Later
it should be implemented in both Qt and Gtk(atleast). So we
can have a base application(say grass) and a set of GUI's
(ggrass,kgrass,wxgrass etc). Initially it can be implemented
in one toolkit and later extend to all.

Layers
-----------
        "thuban" has good support for layer concept. But GRASS needs
additional features like "swipe" feature in ERDAS. Also we should be
able to assign transparency to layers. "Legend" editing should be
easy at display level. (as in thuban?).

Bye

--
Change the rules, or the rules will change you
     ---------Kumaranasan

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

8

Regarding widget toolkits:

I think wxWindows (wxwindows.org) is the way to go. Then it can by built natively for OSX, MS windows, GTK, etc.
I've always been cautious about Qt because of licensing issues on MS windows, but I hear that Qt4 will resolve this.

Regarding comments on interface: One thing that I would love to see is a specific GRASS shell, so when I'm typing in map parameters to a command I can use autocompletion. In the same manner that bash allows you to complete directories and filenames with tab, or shows you a list of possible alternatives if more than one completion exists.

The only way I use d.m right now is to organise the order of displaying of maps. Is there any command-line way to get the list of commands to reproduce the current display?

Joel

William Kyngesburye wrote:

I think the GUI toolkit should run *natively* cross-platform.

GTK: X11. That is, on Mac OS X is requires the X11 environment. I saw the beginnings of a native Mac port, but it could take a while. I'm not sure how it works on Windows, cygwin? I think I saw a well developed native port.

Tcl/Tk: X11. There are native builds of this on Mac and Windows. But, when I tried to use that on Mac OS X I ran into conflicts between X11 stuff and Mac OS X. GRASS would have to be completely divorced from X11.

Qt: native from the ground up. I just started playing with qgis. From the binaries, it's a Mac application (or Windows, or X11), though the GUI widgets are a lot like Windows. I'm trying a build from source (so I can update GDAL in it) and maybe there are some settings to use some more native versions of things (like the open/ save dialogs).

As for a choice of GUI kits, I wonder if would be possible to abstract the GUI functions in a GRASS library, and that will use whichever GUI kit was built into that copy of GRASS. It might even then be possible to plug binaries of the GRASS GUI library into a GRASS binary to switch between GUIs. Maybe start with Qt and add others later. Just a thought.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joel Pitt, Room B534
Bio-Protection & Ecology Division
PO Box 84
Lincoln University 8150
New Zealand

9

On 11/15/2005 11:27 PM, Joel Peter William Pitt wrote:

Regarding comments on interface: One thing that I would love to see is a
specific GRASS shell, so when I'm typing in map parameters to a command
I can use autocompletion. In the same manner that bash allows you to
complete directories and filenames with tab, or shows you a list of
possible alternatives if more than one completion exists.

The cool thing about using your own shell is that you have the same
aliases etc. And most modern shells support autocompletion
configuration. I know bash and tcsh atleas does it. On windows, if the
shell is cmd, then defenately I think that a grass shell would be
better. If we are going to develop a grass shell, then I'm defenately
interested in doing it (:

Check out http://www.sorokine.info/grass-complete/ for bash and tcsh
completion. I haven't tried it yet, but I suppose it will work (;

The only way I use d.m right now is to organise the order of displaying
of maps. Is there any command-line way to get the list of commands to
reproduce the current display?

Mee too. I'd also like to know this (:

--Wolf

--

      |Humpty Dumpty sat on a wall
(o< --|Humpty Dumpty had a great fall
//\ |All the king's horses and all the king's men
V_/_ |Couldn't put Humpty together again.

Wolf Bergenheim

10

Wolf Bergenheim wrote:

On 11/15/2005 11:27 PM, Joel Peter William Pitt wrote:

Regarding comments on interface: One thing that I would love to see is a
specific GRASS shell, so when I'm typing in map parameters to a command
I can use autocompletion. In the same manner that bash allows you to
complete directories and filenames with tab, or shows you a list of
possible alternatives if more than one completion exists.
   
The cool thing about using your own shell is that you have the same
aliases etc. And most modern shells support autocompletion
configuration. I know bash and tcsh atleas does it. On windows, if the
shell is cmd, then defenately I think that a grass shell would be
better. If we are going to develop a grass shell, then I'm defenately
interested in doing it (:

Check out http://www.sorokine.info/grass-complete/ for bash and tcsh
completion. I haven't tried it yet, but I suppose it will work (;

Cool thanks!
This kind of thing should definately be made more prominent or integrated into the GRASS distribution.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Joel Pitt, Room B534
Bio-Protection & Ecology Division
PO Box 84
Lincoln University 8150
New Zealand

11

GTK: X11. That is, on Mac OS X is requires the X11 environment. I
saw the beginnings of a native Mac port, but it could take a while.
I'm not sure how it works on Windows, cygwin? I think I saw a well
developed native port.

gtk for Windows is distributed as a dll installer, e.g. the WinGIMP
download page. GIMP on the Mac runs under X11, but in practice you
double click the gimp icon and you get the gimp program. It isn't really
a hurdle.

[...]

As for a choice of GUI kits, I wonder if would be possible to
abstract the GUI functions in a GRASS library, and that will use
whichever GUI kit was built into that copy of GRASS.

quick prototyping:

all modules are can be run with "--interface-description" to give XML of
all the options etc. Loop through all the module names and capture all
the module interface commands to a file, and go from there.

The PNG driver can create PPM output which you can use to fill windows.

Hamish

12

The only way I use d.m right now is to organise the order of
displaying of maps. Is there any command-line way to get the list of
commands to reproduce the current display?

d.save

Hamish

13

Running 'natively'--or as natively as possible--will make it MUCH easier for
more people to who want to use GRASS to do so. It will also be easier to
learn more of the complexities of GIS and spatial analysis if they can
install it easily and simply run it easily.

TclTk is somewhat easy to work with because it doesn't have to be compiled.
HOWEVER, I now have 3 versions of TclTk on my Mac--the one that comes from
Apple (that GRASS does not use), the X11 version that I prefer, and the aqua
version that Lorenzo Moretti has used to give GRASS an optionally more
Mac-like appearance. Windows users need 2 versions of TclTk because the
version that comes with Cygwin doesn't work with GRASS. (Oh yeah and they
need Cygwin too). Some Linux users need version 8.3 in addition to the
version 8.4 that comes with their system. This is a mess. If we were to go
with TclTk, this would have to be cleaned up. But I don't know if it's
possible.

I also have heard that QT is making an open source version available for
Windows, but don't know the status of that. This is a pretty critical issue,
but perhaps solved already.

As someone else mentioned, GIMP works pretty transparently on my Mac, even
though it runs under X11. So does Inkscape (also GTK I think). Apple gives
away a Mac-specific version of X11, so this is not a problem AFAICT. I've
seen GIMP run on Windows XP and it appears to run natively (ie., no need for
Cygwin or x11 emulation). GTK seems to be widely standard on most Linux
systems too.

Someone also mentioned wxwindows as a platform candidate. I haven't heard of
this. Has anyone else?

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402

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

From: William Kyngesburye <woklist@kyngchaos.com>
Reply-To: William Kyngesburye <kyngchaos@kyngchaos.com>
Date: Tue, 15 Nov 2005 09:43:08 -0600
To: <grass5@grass.itc.it>, <grassgui@grass.itc.it>
Subject: Re: [GRASS5] GRASS GUI

I think the GUI toolkit should run *natively* cross-platform.

GTK: X11. That is, on Mac OS X is requires the X11 environment. I
saw the beginnings of a native Mac port, but it could take a while.
I'm not sure how it works on Windows, cygwin? I think I saw a well
developed native port.

Tcl/Tk: X11. There are native builds of this on Mac and Windows.
But, when I tried to use that on Mac OS X I ran into conflicts
between X11 stuff and Mac OS X. GRASS would have to be completely
divorced from X11.

Qt: native from the ground up. I just started playing with qgis.
From the binaries, it's a Mac application (or Windows, or X11),
though the GUI widgets are a lot like Windows. I'm trying a build
from source (so I can update GDAL in it) and maybe there are some
settings to use some more native versions of things (like the open/
save dialogs).

As for a choice of GUI kits, I wonder if would be possible to
abstract the GUI functions in a GRASS library, and that will use
whichever GUI kit was built into that copy of GRASS. It might even
then be possible to plug binaries of the GRASS GUI library into a
GRASS binary to switch between GUIs. Maybe start with Qt and add
others later. Just a thought.

On Nov 14, 2005, at 11:33 PM, Sajith VK wrote:

Tool kit(TK/GTK/QT)
-----------------------------
Custom application development is very important in
GIS. Hence selection of toolkit decides the way in which
we can develop custom applications based on GRASS. Now each
programmer has his own choice for toolkit. I like Gnome(and uses Gtk),
and similarly someone else may like KDE(and use QT).
So first a generic outline need to be developed. Later
it should be implemented in both Qt and Gtk(atleast). So we
can have a base application(say grass) and a set of GUI's
(ggrass,kgrass,wxgrass etc). Initially it can be implemented
in one toolkit and later extend to all.

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

"History is an illusion caused by the passage of time, and time is an
illusion caused by the passage of history."

- Hitchhiker's Guide to the Galaxy

14

At 07:59, mercoledì 16 novembre 2005, Michael Barton has probably written:

I also have heard that QT is making an open source version available for
Windows, but don't know the status of that. This is a pretty critical
issue, but perhaps solved already.

Yes, solved:
http://www.trolltech.com/products/qt/opensource.html
pc
--
Paolo Cavallini
email+jabber: cavallini@faunalia.it
www.faunalia.it
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953

15

Someone also mentioned wxwindows as a platform candidate. I haven't
heard of this. Has anyone else?

sure, Audacity among others useses it.
  http://audacity.sourceforge.net/

Hamish

16

Thuban (thuban.intevation.org) uses wxwindows.

Someone also mentioned wxwindows as a platform candidate. I haven't heard of
this. Has anyone else?

--
Change the rules, or the rules will change you
     ---------Kumaranasan

17

hi

> The only way I use d.m right now is to organise the order of displaying
> of maps. Is there any command-line way to get the list of commands to
> reproduce the current display?
>

Mee too. I'd also like to know this (:

history

:slight_smile:

jachym

--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/
-----------------------------------------
OFFICE:
Department of Geoinformation Technologies
LDF MZLU v Brnì
Zemìdìlská 3
613 00 Brno
e-mail: xcepicky@node.mendelu.cz
URL: http://mapserver.mendelu.cz
Tel.: +420 545 134 514

18

William Kyngesburye wrote:

GTK: X11. That is, on Mac OS X is requires the X11 environment. I
saw the beginnings of a native Mac port, but it could take a while.
I'm not sure how it works on Windows, cygwin? I think I saw a well
developed native port.

The native Windows port of GTK works well. I got a substantial
GTK/OpenGL application working on Windows with very little effort
(most of the effort was porting opendir/readdir/closedir to
FindFirstFile/FindNextFile).

As for a choice of GUI kits, I wonder if would be possible to
abstract the GUI functions in a GRASS library, and that will use
whichever GUI kit was built into that copy of GRASS. It might even
then be possible to plug binaries of the GRASS GUI library into a
GRASS binary to switch between GUIs. Maybe start with Qt and add
others later. Just a thought.

Abstracting the GUI toolkit is far too much work. This is what
wxWindows and Mozilla's XPFE do, and they're both massive projects.

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