[GRASS-dev] GUI toolkits

GRASS GIS GRASS GIS developer
1

One of the questions that Michael had raised in the earlier
threads concerning toolkits and languages to replace the
tcl/tk interface was the accessibility of development tools
on all platforms. Since there has been some interest in
using Python, I began doing a very cursory examination of
the different toolkits and their associated development
environments. I've used Python for scripting statistical
analyses and database work, but never for GUI work, so it is
something new to me. I've been using Eric3 for my Python
editor but it isn't available on all platforms. When looking
at wxPython I came across PythonCard (and had noticed the
LWN announcement of the new release this week) so I looked
at it briefly and it seems pretty decent. As it was a
toolkit that tries to reduce the complexity of GUI
development and make it more Python like, it seems like a
good idea and something we might want to consider. It is
pure Python so the development tools are available on all
platforms and uses wxPython. From what I can tell, if there
is need for more control than is offered with PythonCard,
wxPython can be coded directly within this environment. In
an earlier life as a Clipper programmer, I used a tool
called Zachary, which automated huge portions of the
application development process but still allowed for the
hand coding of more advanced modules. I found this extremely
handy, and was able to be very productive with those tools.
I realize that a GRASS GUI is an entirely different kind of
animal than end user desktop database apps, but still the
idea of using a single tool has advantages.

I look foward to hearing the opinions of others on the list
about this idea and their experiences with PythonCard (if
any).

Thanks

T
--
Trevor Wiens

2

hallo,

On Fri, May 26, 2006 at 08:44:24AM -0600, twiens wrote:

One of the questions that Michael had raised in the earlier
threads concerning toolkits and languages to replace the
tcl/tk interface was the accessibility of development tools
on all platforms. Since there has been some interest in
using Python, I began doing a very cursory examination of
the different toolkits and their associated development
environments. I've used Python for scripting statistical
analyses and database work, but never for GUI work, so it is
something new to me. I've been using Eric3 for my Python
editor but it isn't available on all platforms. When looking
at wxPython I came across PythonCard (and had noticed the
LWN announcement of the new release this week) so I looked
at it briefly and it seems pretty decent. As it was a
toolkit that tries to reduce the complexity of GUI
development and make it more Python like, it seems like a
good idea and something we might want to consider. It is
pure Python so the development tools are available on all
platforms and uses wxPython. From what I can tell, if there
is need for more control than is offered with PythonCard,
wxPython can be coded directly within this environment. In
an earlier life as a Clipper programmer, I used a tool
called Zachary, which automated huge portions of the
application development process but still allowed for the
hand coding of more advanced modules. I found this extremely
handy, and was able to be very productive with those tools.
I realize that a GRASS GUI is an entirely different kind of
animal than end user desktop database apps, but still the
idea of using a single tool has advantages.

I look foward to hearing the opinions of others on the list
about this idea and their experiences with PythonCard (if
any).

Thanks

T
--
Trevor Wiens

I scripted G-ps.map
(http://les-ejk.cz/?cat=gpsmap) with Glade, because I could not find
anything similar to it for wxWindows. Actually, the reason, why I choosed Gtk
was Glade.

Glade is very nice tool, the configuration files for new gui are stored
in XML, which can be edited directly. I was fearing, how fast will the
new on-the-fly generated gui, but even on my laptop it goes very well.

I do not say, that we should use Gtk, but I thing, tool similar to Glade
for wxWindows would be *very* importand for fast and simple development.

I tryed to make some graphical app. using PythonCard right now and I would say,
glade works a little bit other, IMHO better, way. Also the resulting
file is python code and not XML (or somethign "neutral"),
which means, that the GUI can be created only with python and not from
other languages. Also generating the graphical forms for modules by
g.parser seems simplier as XML rather than python to me - but this will
be done sometime in the future, if ever.

anyway

+1 for python

I thing, this language will bring more potential developers to GRASS

just my 2 cents

Jachym
--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------
OFFICE:
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507

3

One of the questions that Michael had raised in the earlier
threads concerning toolkits and languages to replace the
tcl/tk interface was the accessibility of development tools
on all platforms. Since there has been some interest in
using Python, I began doing a very cursory examination of
the different toolkits and their associated development
environments.

..

I look foward to hearing the opinions of others on the list
about this idea and their experiences with PythonCard (if
any).

We should ask the Thuban devels about the good points and bad points of
Python + wxPython as they've already done a FreeGIS GUI with it,
  http://thuban.intevation.org

I understand the desire to start from scratch but wonder if on the Qt
path why not just work on, or crib from, QGIS+GRASS, and if Wx why not
just make Thuban talk to GRASS via PySWIG, or crib/reuse their front
end?

At minimum we should learn from the others who have gone before us on
the same path about what works, what doesn't, where the problems will
be..

Hamish

4

On Sat, 27 May 2006 17:31:47 +1200
Hamish <hamish_nospam@yahoo.com> wrote:

> One of the questions that Michael had raised in the earlier
> threads concerning toolkits and languages to replace the
> tcl/tk interface was the accessibility of development tools
> on all platforms. Since there has been some interest in
> using Python, I began doing a very cursory examination of
> the different toolkits and their associated development
> environments.
..
> I look foward to hearing the opinions of others on the list
> about this idea and their experiences with PythonCard (if
> any).

We should ask the Thuban devels about the good points and bad points of
Python + wxPython as they've already done a FreeGIS GUI with it,
  http://thuban.intevation.org

I understand the desire to start from scratch but wonder if on the Qt
path why not just work on, or crib from, QGIS+GRASS, and if Wx why not
just make Thuban talk to GRASS via PySWIG, or crib/reuse their front
end?

Personally I am in position to contribute if we choose C++ as a
development language. However my experience with Thuban has been pretty
mixed. When I could get it run, it was pretty nice, but on my systems
it has been broken most of the time and I've never been very motivated
to fix it, because it is just a viewer. I don't know if this is
indicative of wxPython apps in general, but if so this would make me
concerned about using it.

At minimum we should learn from the others who have gone before us on
the same path about what works, what doesn't, where the problems will
be..

Yes, comments from others who've gone down this path would be very
useful.

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)

5

On Sat, 27 May 2006 00:19:27 -0600
Trevor Wiens <twiens@interbaun.com> wrote:

On Sat, 27 May 2006 17:31:47 +1200
Hamish <hamish_nospam@yahoo.com> wrote:

> > One of the questions that Michael had raised in the earlier
> > threads concerning toolkits and languages to replace the
> > tcl/tk interface was the accessibility of development tools
> > on all platforms. Since there has been some interest in
> > using Python, I began doing a very cursory examination of
> > the different toolkits and their associated development
> > environments.
> ..
> > I look foward to hearing the opinions of others on the list
> > about this idea and their experiences with PythonCard (if
> > any).
>
> We should ask the Thuban devels about the good points and bad points of
> Python + wxPython as they've already done a FreeGIS GUI with it,
> http://thuban.intevation.org
>
>
> I understand the desire to start from scratch but wonder if on the Qt
> path why not just work on, or crib from, QGIS+GRASS, and if Wx why not
> just make Thuban talk to GRASS via PySWIG, or crib/reuse their front
> end?

Correcting myself below

Personally I am in NO position to contribute if we choose C++ as a
development language. However my experience with Thuban has been pretty
mixed. When I could get it run, it was pretty nice, but on my systems
it has been broken most of the time and I've never been very motivated
to fix it, because it is just a viewer. I don't know if this is
indicative of wxPython apps in general, but if so this would make me
concerned about using it.

>
> At minimum we should learn from the others who have gone before us on
> the same path about what works, what doesn't, where the problems will
> be..

Yes, comments from others who've gone down this path would be very
useful.

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)

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

--
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)

6

Mybe I'm missing a point here, but why not just help improving th already
excellent qgis+grass?
We're using it a lot in production, and apart from a few bugs and missing
tools, we believe this is the best solution available, especially for the
general GISser.
pc

At 08:21, sabato 27 maggio 2006, Trevor Wiens has probably written:

On Sat, 27 May 2006 00:19:27 -0600

...

>
> Yes, comments from others who've gone down this path would be very
> useful.
>
> 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)

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

7

Am Samstag, den 27.05.2006, 17:31 +1200 schrieb Hamish:

At minimum we should learn from the others who have gone before us on
the same path about what works, what doesn't, where the problems will
be..

Did someone have had a look at FWTools? I'm quite confident Frank knows
by heart shallows and abysms of phyton interfacing to GIS.

Frank, did you follow this discussion? I would appreciate very much to
hear your opinion in this topics.

/Stefan

8

Am Samstag, den 27.05.2006, 00:19 -0600 schrieb Trevor Wiens:

Personally I am in position to contribute if we choose C++ as a
development

I do doubt that using C++ would increase the number of contributors.
It is very difficult to write C++ in a transparent way, which is
essential for debugging and further development by others.

I did some clean-up work in shattered industrial projects using C++.
Most of them had to be rewritten(!) in plain ISO-C. So I would recommend
it only for new projects written top-down and close to a qualified spec.

/Stefan

9

On Sat, 27 May 2006 12:38:28 +0200
Stefan Paulick <stefan.paulick@urbeli.com> wrote:

Am Samstag, den 27.05.2006, 00:19 -0600 schrieb Trevor Wiens:

> Personally I am in position to contribute if we choose C++ as a
> development

Correction. I sent a second e-mail, but I suppose it was missed. Sorry.
It should have read.

I am in NO position to contribute if we choose C++.

I do doubt that using C++ would increase the number of contributors.
It is very difficult to write C++ in a transparent way, which is
essential for debugging and further development by others.

I did some clean-up work in shattered industrial projects using C++.
Most of them had to be rewritten(!) in plain ISO-C. So I would recommend
it only for new projects written top-down and close to a qualified spec.

I agree with you on this point. C++ although powerful, reduces the
number of potential contributors and does not integrate nicely with the
majority of GRASS which is C. If we were to choose a compiled language
for the GUI development, I would choose C over C++.

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)

10

On Sat, 27 May 2006 09:24:35 +0200
Paolo Cavallini <cavallini@faunalia.it> wrote:

Mybe I'm missing a point here, but why not just help improving th already
excellent qgis+grass?
We're using it a lot in production, and apart from a few bugs and missing
tools, we believe this is the best solution available, especially for the
general GISser.
pc

As you may recall this question was asked some time ago and the general
feeling was that a separate GRASS GUI was desirable. The main reasons
stated for that as I recall were:

1. QGIS and GRASS have different goals and target different audiences.
Thus abandoning a GRASS specific GUI reduces the ability of GRASS
developers to guide and develop the tools they want and need.

2. GRASS is primarily written in C so if we want to use a compiled
language, C would be the natural choice.

3. C++ would reduce the number of contributors. Establishing a nice
interpreted environment could increase the ease of development for
future modules.

Personally, I use QGIS as viewer of shapefiles or PostGIS files, but not
for anything else; I prefer GRASS.

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)

11

Trevor Wiens wrote:

As you may recall this question was asked some time ago and the general
feeling was that a separate GRASS GUI was desirable. The main reasons
stated for that as I recall were:

[snip]

2. GRASS is primarily written in C so if we want to use a compiled
language, C would be the natural choice.

This is only relevant if the GUI actually links to GRASS libraries,
which isn't necessarily a good idea. The design of the GRASS libraries
doesn't really lend itself to persistent applications.

Integrating C and C++ code isn't particularly hard; one of the key
design goals of C++ was compatibility with C. The primary objection to
C++ is that it tends to be much harder to "dip into" C++ code than C
code, even if you're equally fluent in both languages.

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

12

At 05:51, domenica 28 maggio 2006, Trevor Wiens has probably written:

1. QGIS and GRASS have different goals and target different audiences.
Thus abandoning a GRASS specific GUI reduces the ability of GRASS
developers to guide and develop the tools they want and need.

I do not understand this. GRASS is very much about powerful GIS analyses. QGIS
is especially aimed at geobrowsing. The integration of the two makes the easy
yet powerful freeGIS most user (actual and potential) want and need.

2. GRASS is primarily written in C so if we want to use a compiled
language, C would be the natural choice.

Right, but do you think separating analysis (in C) from GUI (in C++/Qt) would
cause problems?

3. C++ would reduce the number of contributors. Establishing a nice
interpreted environment could increase the ease of development for
future modules.

Tapping from the relatively large and very active developer base of QGIS
actually increases the number of contributors, leaving grass developers to
concentrate on analysis (see e.g. recent discussions on rater data format,
and the TODO list on vectors sent by Radim) rather than reinventing the
wheel.

Personally, I use QGIS as viewer of shapefiles or PostGIS files, but not
for anything else; I prefer GRASS.

GIS is very much about interoperability, so being able to use shapefiles and
postgis and grass in the same environment is a big plus. Have you tried e.g.
printing a simple map recently?

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

13

The way, QGIS is controled, completly differs from the way, GRASS is
controled. People (like me) like the way and will never use QGIS, because it is something strange.

I thing, GRASS should not be about nice and featurefull GUI. But it
should have "high-toned" GUI - something, which would do things
"the GRASS way", something, which would be fast, small (on diskspace
and on the screen).

Personally I thing, that the new gis.m is too "overstuffed", but as I
did nothing, I say nothing, but "thank you", Michael and Cedric, well
done!

I do not want to be forsed to use QGIS, when I want to digitize my data,
I do not want to be forsed to use QGIS, when I want display my data.
I do want "just rectify" my new raster image and so on.
That's IMHO all, the "new" gui should be about (freedom?).

QGIS and GRASS are looking like Ubuntu and Debian these days to me.

Jachym

P.S. My apologize, if I misunderstand something.

On Sun, May 28, 2006 at 04:15:20PM +0200, Paolo Cavallini wrote:

At 05:51, domenica 28 maggio 2006, Trevor Wiens has probably written:

> 1. QGIS and GRASS have different goals and target different audiences.
> Thus abandoning a GRASS specific GUI reduces the ability of GRASS
> developers to guide and develop the tools they want and need.

I do not understand this. GRASS is very much about powerful GIS analyses. QGIS
is especially aimed at geobrowsing. The integration of the two makes the easy
yet powerful freeGIS most user (actual and potential) want and need.

> 2. GRASS is primarily written in C so if we want to use a compiled
> language, C would be the natural choice.

Right, but do you think separating analysis (in C) from GUI (in C++/Qt) would
cause problems?

> 3. C++ would reduce the number of contributors. Establishing a nice
> interpreted environment could increase the ease of development for
> future modules.

Tapping from the relatively large and very active developer base of QGIS
actually increases the number of contributors, leaving grass developers to
concentrate on analysis (see e.g. recent discussions on rater data format,
and the TODO list on vectors sent by Radim) rather than reinventing the
wheel.

> Personally, I use QGIS as viewer of shapefiles or PostGIS files, but not
> for anything else; I prefer GRASS.

GIS is very much about interoperability, so being able to use shapefiles and
postgis and grass in the same environment is a big plus. Have you tried e.g.
printing a simple map recently?

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

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

--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------
OFFICE:
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507

14

> 2. GRASS is primarily written in C so if we want to use a compiled
> language, C would be the natural choice.

This is only relevant if the GUI actually links to GRASS libraries,
which isn't necessarily a good idea. The design of the GRASS libraries
doesn't really lend itself to persistent applications.

does this mean that Python + SWIG is a bad idea?

Hamish

15

I think that many of us are excited about the Python SWIG interface to
the GRASS API because it affords us the opportunity to write entirely
new modules using a higher-level language than C. These new programs
should obey all the standard GRASS conventions for an independent
program.

If a new GUI is developed using Python + GUI toolkit, that is a
separate issue. Python shouldn't have any problems with a complicated
GUI, but there are apparently limits to its performance. I noticed
that Scribus, a sophisticated drawing program that was originally
developed using only Python has switched to QT (C++) for performance
reasons. I wasn't able to find a document describing what the
performance problems were with Python.

Scribus and a future GUI for GRASS would have similar designs. Maybe
someone should contact the Scribus developers and find out what the
limitations were with Python + GUI toolkit?

David

On 5/28/06, Hamish <hamish_nospam@yahoo.com> wrote:

> > 2. GRASS is primarily written in C so if we want to use a compiled
> > language, C would be the natural choice.
>
> This is only relevant if the GUI actually links to GRASS libraries,
> which isn't necessarily a good idea. The design of the GRASS libraries
> doesn't really lend itself to persistent applications.

does this mean that Python + SWIG is a bad idea?

Hamish

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

--
David Finlayson

16

On Sun, 28 May 2006 16:15:20 +0200
Paolo Cavallini <cavallini@faunalia.it> wrote:

At 05:51, domenica 28 maggio 2006, Trevor Wiens has probably written:

> 1. QGIS and GRASS have different goals and target different audiences.
> Thus abandoning a GRASS specific GUI reduces the ability of GRASS
> developers to guide and develop the tools they want and need.

I do not understand this. GRASS is very much about powerful GIS analyses. QGIS
is especially aimed at geobrowsing. The integration of the two makes the easy
yet powerful freeGIS most user (actual and potential) want and need.

I like them separate. QGIS if I need a quick look at something and
GRASS if I want to do something serious.

> 2. GRASS is primarily written in C so if we want to use a compiled
> language, C would be the natural choice.

Right, but do you think separating analysis (in C) from GUI (in C++/Qt) would
cause problems?

> 3. C++ would reduce the number of contributors. Establishing a nice
> interpreted environment could increase the ease of development for
> future modules.

Tapping from the relatively large and very active developer base of QGIS
actually increases the number of contributors, leaving grass developers to
concentrate on analysis (see e.g. recent discussions on rater data format,
and the TODO list on vectors sent by Radim) rather than reinventing the
wheel.

> Personally, I use QGIS as viewer of shapefiles or PostGIS files, but not
> for anything else; I prefer GRASS.

GIS is very much about interoperability, so being able to use shapefiles and
postgis and grass in the same environment is a big plus. Have you tried e.g.
printing a simple map recently?

Don't even get me started on this one. Ha, ha,... too late.

rant begins

I've worked as a consultant for over 15 years using most of the
different commercial GIS available, and I'll tell you straight, that
they mostly suck when it comes output. I can't even begin to calculate
the number of hours I've spent f***ing around with labels and colours
in drawing programs because the output from the GIS programs was so
bad. In the realm of free software, generating a quality map is
similarly difficult if not worse. psmap is not bad, but it doesn't do
process colours, so it can't be used for publishing without extra
processing. GMT does generate process colours but it's understanding of
file formats is so primitive that xy files have to hand edited to
prevent islands within lakes from being shaded in. QGIS, etc, don't
even begin to address to problem of cartography from the right
approach, IMAO, so will never be able to generate publication quality
output. Over the years after using many different programs, including
some dedicated just to cartography, I think I have a pretty good idea
about what features are needed to make something right the first time
quickly and easily. The old Atlas GIS program was pretty decent in most
aspects before it was bought and castrated by ESRI.

end rant

So my response at this point in time is to become involved in the GRASS
GUI project. The GRASS community is wonderful; even heated discussions
on lists are polite and small contributions are appreciated. This is an
environment in which I feel I can contribute in a meaningful way. Over
the last 3 years as I have worked more and more with GRASS I have begun
to really like the way it works, even though I can see need for
improvement in some areas (eg. memory management in the vector
libaries) where I don't have the time to contribute. A GUI interface,
especially if it is built using straight C or Python is something where
I can help with coding.

gis.m has come a long way, and unlike Jachym, I don't think it is over
blown. I do however like the separation between the gui and the
underlying functionality and I like the idea of being able to create
good tools for the job that can be run independently without a heavy
front end. The basic architecture of QGIS is the monolithic
application, or to put it in ESR terms (cringing...) it is NOT the Unix
approach of many small applications doing one thing well. d.m, gis.m
and whatever are to follow will take this many small applications
approach which lends a flexibility to the end user through the
expressiveness of the CLI, but will also provide the ease of use to the
naive user and hopefully provide some implicit education about how
GRASS works so they will be able to migrate to CLI and scripting for
more advanced work gradually.

Perhaps that more clearly defines my position. I am however just one
voice, although perhaps a bit too loud sometimes considering how little
I've actually contributed to GRASS, and I will contribute as I am able
with whatever direction is chosen.

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)

17

On Sun, 28 May 2006 13:01:25 +0100
Glynn Clements <glynn@gclements.plus.com> wrote:

Trevor Wiens wrote:

> As you may recall this question was asked some time ago and the general
> feeling was that a separate GRASS GUI was desirable. The main reasons
> stated for that as I recall were:

[snip]

> 2. GRASS is primarily written in C so if we want to use a compiled
> language, C would be the natural choice.

This is only relevant if the GUI actually links to GRASS libraries,
which isn't necessarily a good idea. The design of the GRASS libraries
doesn't really lend itself to persistent applications.

I know and have quoted you recently on this issue.

Integrating C and C++ code isn't particularly hard; one of the key
design goals of C++ was compatibility with C. The primary objection to
C++ is that it tends to be much harder to "dip into" C++ code than C
code, even if you're equally fluent in both languages.

I was thinking more in terms of using a single language for
development; adding languages adds complexity to the maintenance of the
application. Right now we have two (C++ modules excepted), one compiled
and one interpreted. From my experience and reading this is generally a
good idea of keeping code that needs speed in C and put the front end
in something that allows for easy development and modification. C++
doesn't help on either front, so it is probably a non-starter. Of
languages that are available, suitable for the task and easy to
maintain, we don't have a lot of options other and Ruby, Python or
OCaml. I don't know however if there are cross platform tools
available for Ruby or OCaml, further how many people are familiar with
those tools. I suppose I could also add Objective C to the list, but
again there are availability issues and a dearth of developers. As I
see it now, after all the discussion on this list over the last 6
months we have two reasonable choices; develop the next GUI for
GRASS using C, which pretty much means GTK AFAIK, or Python.

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)

18

Am Sonntag, den 28.05.2006, 18:59 +0200 schrieb Jachym Cepicky:

The way, QGIS is controled, completly differs from the way, GRASS is
controled. People (like me) like the way and will never use QGIS, because it is something strange.

? ... Oh, yes, Icons are made by the devil and do poison your brain. In
the short term, you will end up asking your boss for M$ products!

I thing, GRASS should not be about nice and featurefull GUI. But it
should have "high-toned" GUI - something, which would do things
"the GRASS way", something, which would be fast, small (on diskspace
and on the screen).

I started programming with dip switches, shifting in assembler hex code.
So PCs should never have a keyboard and MUST have output for 40x25 text
display. You get the point? :wink:

Personally I thing, that the new gis.m is too "overstuffed", but as I
did nothing, I say nothing, but "thank you", Michael and Cedric, well
done!

A good GUI is worth pure gold when making presentations to buyers and
descition makers. Did you ever try to sell a command line tool? A GUI
gives identity to grass. This is one of the reasons why Microsoft
products sell much better than unix stuff.

I do not want to be forsed to use QGIS, when I want to digitize my data,
I do not want to be forsed to use QGIS, when I want display my data.

agreed - does gis.m force someone to use it?

I do want "just rectify" my new raster image and so on.
That's IMHO all, the "new" gui should be about (freedom?).

QGIS and GRASS are looking like Ubuntu and Debian these days to me.

The masses do love Ubuntu; it does allows to use linux without creeping
along a command line. I feel bad, but I love Ubunto too....

Graphical interfaces ARE state of the art and DO help occasional user to
stay tuned. Grass without full featured GUI is like delivering a BMW
without gasoline and wooden tyres.

/Stefan

19

One (crucial) difference: Ubuntu is a fork of Debian, QGIS is an independent
project that only adds value to grass, not detracting anything from it.
Please consider, however, that power users like you are not the average, not
even among freegissers. Do we want GRASS being widely used?
But of couse, freedom is our main asset!
pc

At 18:59, domenica 28 maggio 2006, Jachym Cepicky has probably written:

People (like me) like the way and will never use QGIS, because
it is something strange.

QGIS and GRASS are looking like Ubuntu and Debian these days to me.

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

20

Sorry for the spam message. I send the e-mail again and I hope,
everything works now:

?
On Mon, May 29, 2006 at 07:12:35AM +0200, Stefan Paulick wrote:

Am Sonntag, den 28.05.2006, 18:59 +0200 schrieb Jachym Cepicky:
> The way, QGIS is controled, completly differs from the way, GRASS is
> controled. People (like me) like the way and will never use QGIS, because it is something strange.

? ... Oh, yes, Icons are made by the devil and do poison your brain. In
the short term, you will end up asking your boss for M$ products!

no, that is not the point. I like icons too. Trevor wrote it later in
this thread: Where QGIS is monolitic, GRASS is modular. To get it run on
not so good computer (or compile it) takes to much time.

>
> I thing, GRASS should not be about nice and featurefull GUI. But it
> should have "high-toned" GUI - something, which would do things
> "the GRASS way", something, which would be fast, small (on diskspace
> and on the screen).

I started programming with dip switches, shifting in assembler hex code.
So PCs should never have a keyboard and MUST have output for 40x25 text
display. You get the point? :wink:

No. Modularity. Qgis is slow and the new gui takes just too much space
on ny 800x600 screen. With GRASS it is possible to work on such screen.

>
> Personally I thing, that the new gis.m is too "overstuffed", but as I
> did nothing, I say nothing, but "thank you", Michael and Cedric, well
> done!

A good GUI is worth pure gold when making presentations to buyers and
descition makers. Did you ever try to sell a command line tool? A GUI
gives identity to grass. This is one of the reasons why Microsoft
products sell much better than unix stuff.

I thought, GRASS GUI should be IMHO done the way, gis.m is done. When I
wrote "overstuffed", I just thing, that too many functions are done by
the gui, where command line is faster, but it is not possible to acess
the monitors from command line :expressionless: . But I do not know, how to do it
better. If I would sell GRASS to anybody, I would offer him QGIS
(wingrass) at first place. But that is not the point IMO.

>
> I do not want to be forsed to use QGIS, when I want to digitize my data,
> I do not want to be forsed to use QGIS, when I want display my data.

agreed - does gis.m force someone to use it?

> I do want "just rectify" my new raster image and so on.
> That's IMHO all, the "new" gui should be about (freedom?).
>
> QGIS and GRASS are looking like Ubuntu and Debian these days to me.

The masses do love Ubuntu; it does allows to use linux without creeping
along a command line. I feel bad, but I love Ubunto too....

Graphical interfaces ARE state of the art and DO help occasional user to
stay tuned. Grass without full featured GUI is like delivering a BMW
without gasoline and wooden tyres.

/Stefan

If you say, that gis.m is full featured GUI (with WRT Tcl/Tk limitations
and Xdriver usage), then I would aggree with you.

Sorry, I do not have BMW, but I feel, I would not aggree with your
sample. BWM without gasolin nad with wooden tyres is not useable. GRASS
is IMHO more like land rover with kerosene in his tank.

I woul say, we do agree with each other, Stefan, but we are calling
same things by other words. If you do not thing so, please tell me.
If Silke would be arround, maybe she would be able to tell you my opinion
better, than me.

Jachym

--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------
OFFICE:
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507