I have written GRASS extension for QGIS, which can display GRASS 5.1
vectors and attached attributes. It can work outside GRASS session,
with maps from more locations/gisdbases:
http://mpa.itc.it/radim/qgis/
Radim
On Tue, 24 Jun 2003, Radim Blazek wrote:
I have written GRASS extension for QGIS, which can display GRASS 5.1
vectors and attached attributes. It can work outside GRASS session,
with maps from more locations/gisdbases:
http://mpa.itc.it/radim/qgis/Radim
I thought someone would have replied to this by now but they haven't so I
will. Radim- do you think QGIS could be *the* GUI for GRASS? Now there is
GRASS++ for reading GRASS vectors and already libgrass for rasters. Of
course closer integration would be more desirable.
I just think it would fit really well as all the basic half-hearted GUI
stuff in GRASS could be removed and GRASS left as a mainly command-line
oriented 'back end' processing system for QGIS. The advanced analysis
functions could still be accessed through command-line (e.g. something
like AutoCAD where you still have a command-line at the bottom of the
screen although it is mostly GIU-oriented) or tcltkgrass-style
GUI boxes, but all the common display operations for people who like
their GIS to do automated cartography, could be accessed through the QGIS
GUI.
One of the things I don't like about GRASS 5.1 (from my very limited
experience testing it) is that there are GUI boxes popping up everywhere and
they are all Tcl/Tk which is very clunky and slow and not as nice to look
at as modern GUIs like Gtk or Qt. In fact I don't like GUIs at all and
prefer to do most of my work from the command-line. If the extensive GUI
was a totally separate project (e.g. part of QGIS) it would be such a much
tidier interface I think. It would also be easier for developers who want
to work on the GUI to do it without having to become completely familiar
with GRASS first. And the GRASS developers could just concentrate on the
core capabilities and algorithms etc.
This ties in with Markus' e-mail about release branches: it would be nice
to have the capabilities of the new vector engine in GRASS 5.1 without all
the 'side-effects' of GRASS 5.1, e.g. the GUIs for d.what.vect and
d.where etc., having to work with a different build system and the awkwardness
of the 'make mix' system, not having sites format in 5.1, the lack of testing
of everything on OSs other than Linux (although I suppose that is just the
way things are going these days).
One reason I wanted to see the old developers mailing list is that I was
wondering what discussion there had been and why GRASS 5.1 is in a
separate CVS module and not just a branch in the GRASS module. I have
never been able to find much justification for that.
Anyway I suppose it depends on QGIS being good enough and people thinking
it is heading in the right direction, but perhaps even the QGIS people
would like to link to GRASS for back-end data processing?
That's just a few of my ideas thrown out for discussion anyway,
Paul
On Fri, Jul 04, 2003 at 02:02:36PM +0100, Paul Kelly wrote:
On Tue, 24 Jun 2003, Radim Blazek wrote:
> I have written GRASS extension for QGIS, which can display GRASS 5.1
> vectors and attached attributes. It can work outside GRASS session,
> with maps from more locations/gisdbases:
> http://mpa.itc.it/radim/qgis/
I've asked Radim in personal mail what his technical evaluation was
to decide to add it to QGIS and not Thuban.
But we refused to answer this question so far
fearing that I would only try to convince him
that his arguments are wrong.. 
If the extensive GUI was a totally separate project
(e.g. part of QGIS) it would be such a much
tidier interface I think. It would also be easier for developers who want
to work on the GUI to do it without having to become completely familiar
with GRASS first. And the GRASS developers could just concentrate on the
core capabilities and algorithms etc.
A vision like this for GRASS has been debated a couple of times before
as I remember. Of course it is a good vision, but there also might
be reasons why it did not become a reality in one form or another.
My attempts to exlain this:
- The approaches to general cartographic or geographic
viewers were not very advanced. The FreeGIS project
led to quite some synergic effects in that respects.
- GRASS was not designed to be an interactive application.
This structure will always be visible and is a reason
why interactive geo viewers tend to use their own approach.
- Nobody was willing to long term commit to the work.
This is understandable as a new gui in GTK or QT
would for some parts just be a reimplementation of the
working tcl/tk Gui unless the GRASS structure would be
majorly changed.
This ties in with Markus' e-mail about release branches: it would be nice
to have the capabilities of the new vector engine in GRASS 5.1 without all
the 'side-effects' of GRASS 5.1, e.g. the GUIs for d.what.vect and
d.where etc., having to work with a different build system and the awkwardness
of the 'make mix' system, not having sites format in 5.1, the lack of testing
of everything on OSs other than Linux (although I suppose that is just the
way things are going these days).
As written before we want as some time make real 5.1 releases
as tarballs without make mix. Then we also want to switch to 5.1
as main development branch.
Lack of testing on other system then just GNU/Linux
only depends on the offered help. As with many Free Software projects
GRASS is driven by volenteers contributions and subsequently their needs.
If nobody stand up to help with ports and testing on other platforms,
the support will naturally decline. This is not a drawback, but an advantage.
One reason I wanted to see the old developers mailing list is that I was
wondering what discussion there had been and why GRASS 5.1 is in a
separate CVS module and not just a branch in the GRASS module. I have
never been able to find much justification for that.
Being seminal in introducing CVS for the GRASS development
I can give you the short or the long story.
The short one is that people wanted to reorganise a lot,
GRASS is a huge pile with only parts that have active maintainers,
code duplication and all that.
If you want to clean up things CVS does not preserve history well.
Moving and renaming is not really supported in CVS, thus you loose
the history and the ability to really have different branches.
Additionally we needed a place for highly unstable changes for a while
and most developers are not so accustomed with CVS that
it happened a couple of times that commit would destabilise the CVS version.
So having a stable and develpment tree makes a lot of sense.
Anyway I suppose it depends on QGIS being good enough and people thinking
it is heading in the right direction, but perhaps even the QGIS people
would like to link to GRASS for back-end data processing?
Thuban would be another candidate (thuban.intevation.de)
as I would suggest wxPython or wxWindows in general
if a new GUI should be written for GRASS.
The main advantage about wxWindows is that is is a cross-platform
Free Software application framework
(GTK only starts to be cross-platform and QT is not free software
on most platforms.)
Bernhard
Paul Kelly wrote:
One reason I wanted to see the old developers mailing list is that I was
wondering what discussion there had been and why GRASS 5.1 is in a
separate CVS module and not just a branch in the GRASS module. I have
never been able to find much justification for that.
AFAIK, the main reason is that there wouldn't be much point in it
being a branch; all of the files are in different places, which
basically means that they are different files as far as CVS is
concerned.
--
Glynn Clements <glynn.clements@virgin.net>
Paul Kelly wrote:
I thought someone would have replied to this by now but they haven't so I
will. Radim- do you think QGIS could be *the* GUI for GRASS?
QGIS uses Qt, which is non-free on Windows (there is a
"non-commercial" version of Qt for Windows, but it isn't compatible
with the GPL).
--
Glynn Clements <glynn.clements@virgin.net>
On Friday 04 July 2003 15:02, Paul Kelly wrote:
I thought someone would have replied to this by now but they haven't so I
will. Radim- do you think QGIS could be *the* GUI for GRASS?
It will be one of GUIs for GRASS, and it could be *the* GUI at least
for X-Windows. But this I would left to natural evolution.
GUI was discussed many times in this list, without any conclusion.
If the right toolkit is not obvious, we can try more. It is not
my suggestion for future development, it is just the situation
we have now, short summary:
- grass/unused/tcltkgrass (it is realy viewer, not menu for commands)
- d.dm/d.m
- GRASS/Qt
- I know about people working on Java based interface. Are you here?
- GUI for iPAQ written by Carl Worth
- once I have seen a screenshot of complete nice GUI for GRASS,
but it was not released as open source yet (can we see the screenshot Marcus?)
- I started Java interface 2 years ago, it was pure java (no c code)
(http://mpa.itc.it/radim/g50/gratia.jpg)
- QGIS+GRASS
This is one of a few (dis)advantages in OS development, you don't need
to follow what strategists say.
Now there is
GRASS++ for reading GRASS vectors and already libgrass for rasters. Of
course closer integration would be more desirable.
Occasionally I am working on rasters in GRASS++ and QT. I think that
applications using libgrass could use directly shared libraries
from grass51.
One of the things I don't like about GRASS 5.1 (from my very limited
experience testing it) is that there are GUI boxes popping up everywhere
and they are all Tcl/Tk which is very clunky and slow and not as nice to
look at as modern GUIs like Gtk or Qt. In fact I don't like GUIs at all and
prefer to do most of my work from the command-line. If the extensive GUI
was a totally separate project (e.g. part of QGIS) it would be such a much
tidier interface I think. It would also be easier for developers who want
to work on the GUI to do it without having to become completely familiar
with GRASS first. And the GRASS developers could just concentrate on the
core capabilities and algorithms etc.This ties in with Markus' e-mail about release branches: it would be nice
to have the capabilities of the new vector engine in GRASS 5.1 without all
the 'side-effects' of GRASS 5.1, e.g. the GUIs for d.what.vect and
d.where etc., having to work with a different build system and the
awkwardness of the 'make mix' system, not having sites format in 5.1, the
lack of testing of everything on OSs other than Linux (although I suppose
that is just the way things are going these days).
GUI boxes everywhere? No, I cannot believe. Are you running all commands
without options? d.what.vect should open GUI only if run without parameters
and no map is displayed in monitor. Anyway, you can disable automaticaly
generated GUI by setting enviroment variable GRASS_UI_TERM=1. Then remain
v.format, which you can avoid by editing 'frmt' in text editor
or using g.gisenv.
v.digit, but here I insist that it is more productive with GUI
than with old text interface, and time spent by editing is
always much longer than startup.
g.mapsets, use command line options
d.m, don't run it
Yes, I have never seen anybody using GRASS GUI, it is there only
for marketing (I am using d.m, g.mapsets and v.digit).
Idea is that beginner gets GUI and experienced user like you can go around.
If you think that s.* should be in 5.1, put it there. I would prefere
binmix, but it can be in source as well. But we should decide
if it is temporary solution, to be replaced by v.* or if 5.2 will be released
with s.*.
One reason I wanted to see the old developers mailing list is that I was
wondering what discussion there had been and why GRASS 5.1 is in a
separate CVS module and not just a branch in the GRASS module. I have
never been able to find much justification for that.
5.1 is separate tree because it was made a decision to change
directory structure (grass/documents/new_directory_structure.txt).
And it is there so long because, when we started with David to work
on new vectors, we needed some system to share the code.
Anyway I suppose it depends on QGIS being good enough and people thinking
it is heading in the right direction, but perhaps even the QGIS people
would like to link to GRASS for back-end data processing?
I think that QGIS should be only used to display/query/edit GRASS maps
and should not be mixed with interface for GRASS commands.
This could be other project integrating GUI startup, menu and GUI for commands,
QGIS and command line.
Radim
On Mon, Jul 07, 2003 at 10:59:55AM +0200, Radim Blazek wrote:
On Friday 04 July 2003 15:02, Paul Kelly wrote:
> I thought someone would have replied to this by now but they haven't so I
> will. Radim- do you think QGIS could be *the* GUI for GRASS?It will be one of GUIs for GRASS, and it could be *the* GUI at least
for X-Windows. But this I would left to natural evolution.
GUI was discussed many times in this list, without any conclusion.
If the right toolkit is not obvious, we can try more. It is not
my suggestion for future development, it is just the situation
we have now, short summary:
- grass/unused/tcltkgrass (it is realy viewer, not menu for commands)
(this is C source code)
- d.dm/d.m
- GRASS/Qt
http://navicon.dk/web/normal.php?pageid=92
- I know about people working on Java based interface. Are you here?
- GUI for iPAQ written by Carl Worth
(optimized for moving objects on the map)
- once I have seen a screenshot of complete nice GUI for GRASS,
but it was not released as open source yet (can we see the screenshot Marcus?)
Here:
http://mpa.itc.it/markus/tmp/lockheedgui8bit.png
(130kb)
- I started Java interface 2 years ago, it was pure java (no c code)
(http://mpa.itc.it/radim/g50/gratia.jpg)
- QGIS+GRASS
http://mpa.itc.it/radim/qgis/index.html
[...]
Markus
On Friday 04 July 2003 17:21, Bernhard Reiter wrote:
I've asked Radim in personal mail what his technical evaluation was
to decide to add it to QGIS and not Thuban.
But we refused to answer this question so far
fearing that I would only try to convince him
that his arguments are wrong..
That's true, discussing GUI toolkits is only wasting of time, you can find
many such discussions on the Internet including GRASS archives if you want.
Radim
On Mon, Jul 07, 2003 at 11:22:46AM +0200, Radim Blazek wrote:
On Friday 04 July 2003 17:21, Bernhard Reiter wrote:
> I've asked Radim in personal mail what his technical evaluation was
> to decide to add it to QGIS and not Thuban.
> But we refused to answer this question so far
> fearing that I would only try to convince him
> that his arguments are wrong..That's true, discussing GUI toolkits is only wasting of time, you can find
many such discussions on the Internet including GRASS archives if you want.
My question was not about discussion toolkits,
but about our opinion about Thuban and QGIS.
I want to know what makes people prefer one over the other.
Naturally I can't and never would question reasons that I don't know.
From your answer I now conclude that your main reason
was the toolkit of QGIS: Qt.
Also discussions about advantages and disadvantages of toolkits
regarding specific tasks are quite useful.
I cannot imagine a better base for good decisions.
So general discussions about toolkits that you've referred to
are not specific enough for GRASS GUIs.
Bernhard
On Mon, Jul 07, 2003 at 10:59:55AM +0200, Radim Blazek wrote:
On Friday 04 July 2003 15:02, Paul Kelly wrote:
> I thought someone would have replied to this by now but they haven't so I
> will. Radim- do you think QGIS could be *the* GUI for GRASS?It will be one of GUIs for GRASS, and it could be *the* GUI at least
for X-Windows. But this I would left to natural evolution.
GUI was discussed many times in this list, without any conclusion.
If the right toolkit is not obvious, we can try more. It is not
my suggestion for future development, it is just the situation
we have now, short summary:
- grass/unused/tcltkgrass (it is realy viewer, not menu for commands)
- d.dm/d.m
- GRASS/Qt
- I know about people working on Java based interface. Are you here?
- GUI for iPAQ written by Carl Worth
- once I have seen a screenshot of complete nice GUI for GRASS,
but it was not released as open source yet (can we see the screenshot Marcus?)
- I started Java interface 2 years ago, it was pure java (no c code)
(http://mpa.itc.it/radim/g50/gratia.jpg)
- QGIS+GRASS
For the OSSIM grass bridge we had started on a python interface
to the libgrass5. It wasn't completed, see an old screenshot at:
ftp://intevation.de/users/bernhard/ossimbridge
What was also started at this point was the possiblity
of grass commands to output information about the needed parameters.
This would allow GUIs to build simple interfaces automatically
for commands. Probably this still is a good idea to help
GUI development in the long run.
On Monday 14 July 2003 15:36, Bernhard Reiter wrote:
From your answer I now conclude that your main reason
was the toolkit of QGIS: Qt.
Yes, in fact I started with GRASS/QT and downloaded QGIS only as other
inspiration but in the end, I decided for QGIS.
Radim