[GRASS5] joining GRASS development

GRASS GIS GRASS GIS developer
1

Hello, GRASS developers,

I would like to join GRASS 5.7 development officially.

Some of you may know that I wrote some spatial prediction
modules for GRASS 5.4 and that they are available from
Michael Barton's GRASS pages.

my intention as an archaeological researcher is mainly
to enhance GRASS 5 functionality in a number of fields where
I think it is still lacking:

1. spatial statistics and point pattern analysis:
  - needed for teaching students and basic research
    (w/o the user having to install and use R)
  - basic signficance and spatial autocorrelation tests
  - advanced voronoi tesselation including weighted voronoi diagrams

2. geophysical analysis
  - would love to be able to analyse data from the field in
    GRASS in a straight-forward way
  - worked on a whitepaper together with Michael Barton and
    Craig Funkmeister and other contributors,
    but after the first revision was posted on the GRASS user
    list, there was no more feedback
  - still think that a geophysical framework would be great for
    GRASS and would want to keep working on it

3. probabilistic analysis
  - extend functionality of predictive modelling tools to vector
          and site evidence maps
  - create a basic framework for bayesian modelling and inference

4. Several smaller things
  - transparent overlay of raster and vector layers
  - misc modules that make things a bit easier for beginners

5. GUI things
  - a simple colormap editor
  - a new menu entry "Extensions" in the GIS manager through which
    packages with distinct functionality (such as predictive modelling)
    can be installed (using binaries) into the user's current GRASS
    installation. Such an extension manager should also make it possible
          to retreive updates over the internet, merge package documentation
          with the GRASS doc tree, cleanly remove installed packages and
          provide GUI forms for all modules included in a package.

These are the things I am currently working on, there are many more smaller items
on my list.
I feel that to really start with GRASS 5.7 programming, I would need more detailed
information on the current vector engine:

- where can complete API documentation be found?
- which parts of the API are stable and which are still in development or unimplemented?
- is there a short text that could get me started with 5.7 vector programming?

Best regards,

Benjamin

2

Benjamin,

This is great that you're interested in bringing your skills and interests
to GRASS development. As you know, I would be very happy to see the new
functions that you'd like to develop. This would make GRASS a preeminent
application for spatial technology in archaeology.

With regard to the extensions menu, Paoli Cavelli (sp?), Lorenzo Moretti, I,
and several others have discussed such a system conceptually. This would be
very nice. Paoli today suggested that R would be a good model to start with
in the way it can download and install a large suite of add-on modules. The
qGIS plugin system is another possible model to look at.

Thanks for helping.
Michael

On 12/10/04 10:15 AM, "Benjamin Ducke" <benducke@compuserve.de> wrote:

Hello, GRASS developers,

I would like to join GRASS 5.7 development officially.

Some of you may know that I wrote some spatial prediction
modules for GRASS 5.4 and that they are available from
Michael Barton's GRASS pages.

my intention as an archaeological researcher is mainly
to enhance GRASS 5 functionality in a number of fields where
I think it is still lacking:

1. spatial statistics and point pattern analysis:
- needed for teaching students and basic research
(w/o the user having to install and use R)
- basic signficance and spatial autocorrelation tests
- advanced voronoi tesselation including weighted voronoi diagrams

2. geophysical analysis
- would love to be able to analyse data from the field in
GRASS in a straight-forward way
- worked on a whitepaper together with Michael Barton and
Craig Funkmeister and other contributors,
but after the first revision was posted on the GRASS user
list, there was no more feedback
- still think that a geophysical framework would be great for
GRASS and would want to keep working on it

3. probabilistic analysis
- extend functionality of predictive modelling tools to vector
          and site evidence maps
- create a basic framework for bayesian modelling and inference

4. Several smaller things
- transparent overlay of raster and vector layers
- misc modules that make things a bit easier for beginners

5. GUI things
- a simple colormap editor
- a new menu entry "Extensions" in the GIS manager through which
packages with distinct functionality (such as predictive modelling)
can be installed (using binaries) into the user's current GRASS
installation. Such an extension manager should also make it possible
          to retreive updates over the internet, merge package documentation
          with the GRASS doc tree, cleanly remove installed packages and
          provide GUI forms for all modules included in a package.

These are the things I am currently working on, there are many more smaller
items
on my list.
I feel that to really start with GRASS 5.7 programming, I would need more
detailed
information on the current vector engine:

- where can complete API documentation be found?
- which parts of the API are stable and which are still in development or
unimplemented?
- is there a short text that could get me started with 5.7 vector programming?

Best regards,

Benjamin

____________________
C. Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

3

Hi there,

I just made my first steps with GRASS 5.7 coding and tried to compile
and install a simple raster module and a library with auxillary functions.
First of all, I would like to say that I am pretty impressed with the
"new" codebase. The transition worked very smoothly for me, so far, and
everything is a lot more intuitive than it was with GRASS 5.4 and gmake.
Great job!

Here are some questions I need answered to make some more progress:

1. GUI:

a) Is there an official agreement among 5.7 developers
to switch the GUI to Qt/qGIS and drop the Tcl/Tk GUI altogether?
If so, how does all the GRASS functionality contained in current GIS
Manager fit into qGIS? What about the Tk runtime forms (I thought they were quite nice)?

b) Is there any way to control how the runtime Tk forms are build by the G_parser() function?

2. Make and Install process

a) Am I right in assuming, that "gmake" has been replaced with a standard "make" process
and is no longer important?

b) Some of my programs use shared code that I compiled as a library called "gt".
I have put the lib headers in "include" and the code in "lib/gt" is that
where it belongs?

c) If I execute "make" in my module's subdir, the binary gets copied into my source tree.
I would rather have it copied right into the system-wide installation dir in /usr/local.
Is there a simple way to do it with the local Makefile rather than having to call
"make inst" from the top level?

3. Documentation

a) it looks like the text man pages have been dropped?

I have downloaded the GRASS 5.7 progman files but would be thankful for any
additional source of information on GRASS 5.7 coding that someone could point me to.

Thanks,

Benjamin

On Sun, 12 Dec 2004 08:50:57 +0100
Paolo Cavallini <cavallini@faunalia.it> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks for your help Ben! It is much needed.
I think an easy way to install new modules is much needed (have you seen the
mail from Roger Bivand?). On the other hand, I would not spend time on the
GUI (plans are to use qgis for this, instead of the gis manager).
All the best.
pc

4

Benjamin Ducke wrote:

Hi there,
Here are some questions I need answered to make some more progress:

1. GUI:

If so, how does all the GRASS functionality contained in current GIS
Manager fit into qGIS? What about the Tk runtime forms (I thought they were quite nice)?

I want to work on QGIS again after GRASS 6.0.0 release. I would like to add some sort of easy to use GUI for GRASS modules, probably a combination of description generated by module and predefined options for each task. Suggestions are welcome.

b) Is there any way to control how the runtime Tk forms are build by the G_parser() function?

2. Make and Install process

a) Am I right in assuming, that "gmake" has been replaced with a standard "make" process
and is no longer important?

Yes.

b) Some of my programs use shared code that I compiled as a library called "gt".
I have put the lib headers in "include" and the code in "lib/gt" is that
where it belongs?

Yes.

c) If I execute "make" in my module's subdir, the binary gets copied into my source tree.
I would rather have it copied right into the system-wide installation dir in /usr/local.
Is there a simple way to do it with the local Makefile rather than having to call
"make inst" from the top level?

I dont think so.

Radim

5

On 12/10/04 10:15 AM, "Benjamin Ducke" <benducke@compuserve.de> wrote:

> Hello, GRASS developers,
>
> I would like to join GRASS 5.7 development officially.

Benjamin,

you are welcome!

...

> I feel that to really start with GRASS 5.7 programming, I would need more
> detailed information on the current vector engine:
>
> - where can complete API documentation be found?

If you run in the source code:

make pdfdocs
or
make htmldocs

the API docs are generated using doxygen. It's not yet complete:

- the function descritions I have completely merged
- the text chapters of the 5.3 progman are only partially merged
  (required Latex to HTML conversion which is not complicated for
   the texts, just time consuming)

For the latter help is needed, I don't manage to do it the next
months.

> - which parts of the API are stable and which are still in development or
> unimplemented?

WYSIWYG - What you see is what you get. For 5.7 things are intended to
be sort of stable now besides bugfixing. As far as I know, no plans for
raster improvements.

> - is there a short text that could get me started with 5.7 vector programming?

Yep:

http://grass.gdf-hannover.de/twiki/bin/view/GRASS/GrassProgrammingHowto

plus above mentioned docs
plus existing modules (maybe the best way)

Best regards,

Markus

6

On Mon, Dec 13, 2004 at 10:02:31AM +0100, Radim Blazek wrote:

Benjamin Ducke wrote:
>Hi there,
>Here are some questions I need answered to make some more progress:

...

>c) If I execute "make" in my module's subdir, the binary gets copied into
>my source tree.
>I would rather have it copied right into the system-wide installation dir
>in /usr/local.
>Is there a simple way to do it with the local Makefile rather than having
>to call
>"make inst" from the top level?

I dont think so.

Yes, it's possible (see INSTALL file):

"COMPILING INDIVIDUAL MODULES - OWN MODULES

Compiling own GRASS 5.7 modules or modified modules:
Simply run "make" in the appropriate directory
and then install with "INST_NOW=y make".
It is not necessary to install the full distribution.
You may want to make an alias: alias gmake='INST_NOW=y make'
"

Markus

7

Benjamin Ducke wrote:

Here are some questions I need answered to make some more progress:

b) Is there any way to control how the runtime Tk forms are build by the G_parser() function?

The only factors affecting the construction of individual dialogs are
the values stored in the structures returned from calls to
G_define_{module,option,flag} prior to calling G_parser().

G_parser() essentially converts those structures to Tcl code then
passes them to lib/gis/gui.tcl. See that file to determine how the
various fields are used.

2. Make and Install process

a) Am I right in assuming, that "gmake" has been replaced with a standard "make" process
and is no longer important?

Correct.

b) Some of my programs use shared code that I compiled as a library called "gt".
I have put the lib headers in "include" and the code in "lib/gt" is that
where it belongs?

If it will ultimately be used by more than one program, then it
probably belongs under lib.

c) If I execute "make" in my module's subdir, the binary gets copied into my source tree.
I would rather have it copied right into the system-wide installation dir in /usr/local.
Is there a simple way to do it with the local Makefile rather than having to call
"make inst" from the top level?

Try:
  make ARCH_DISTDIR=/usr/local/grass-5.7.cvs

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

8

my intention as an archaeological researcher is mainly
to enhance GRASS 5 functionality in a number of fields where
I think it is still lacking:

1. spatial statistics and point pattern analysis:

just some ideas of things that need to be done for 5.7:

  r.univar: finish extended statistics: mode, median, quartiles..

  r.cellstats: port of 5.4's s.cellstats

  merge r.sum, r.average, r.median, r.mode into r.statistics (status?)

2. geophysical analysis
  - would love to be able to analyse data from the field in
    GRASS in a straight-forward way

v.in.garmin is nice.

4. Several smaller things
  - transparent overlay of raster and vector layers

not with the current display monitor code..

- is there a short text that could get me started with 5.7 vector
programming?

"make pdfdocs" + see the doc/vector/ directory in the 5.7 source tree.

Hamish

9

I have added several updates for rst, including crossvalidation option
It is not finished yet, but almost everything runs OK, except larger (500K +) vector
point files with z stored as attribute (if you store the variable that you want to
interpolate as z coordinate - layer=0 it runs fine). Crossvalidation needs some speed-up too
and I plan to add a less accurate but faster and probably sufficient approximation in near future.
I would like to remove the confusing dmax option (it adds points on contours if the given
points are farther appart than dmax) - please let me know if anybody needs it (I will
then keep it and try to better explain it).

Please let me know if something that I did not mention does not work,

Helena

10

On Mon, Dec 13, 2004 at 11:31:12PM -0500, Helena wrote:

I have added several updates for rst, including crossvalidation option
It is not finished yet, but almost everything runs OK, except larger (500K
+) vector
point files with z stored as attribute (if you store the variable that you
want to
interpolate as z coordinate - layer=0 it runs fine). Crossvalidation needs
some speed-up too
and I plan to add a less accurate but faster and probably sufficient
approximation in near future.
I would like to remove the confusing dmax option (it adds points on
contours if the given
points are farther appart than dmax) - please let me know if anybody needs
it (I will
then keep it and try to better explain it).

Please let me know if something that I did not mention does not work,

Helena,

to make it compile, I have applied the following change in CVS:

RCS file: /grassrepository/grass51/lib/rst/interp_float/interpf.h,v
retrieving revision 1.5
diff -u -r1.5 interpf.h
--- interpf.h 14 Dec 2004 04:06:07 -0000 1.5
+++ interpf.h 14 Dec 2004 08:54:17 -0000
@@ -16,13 +16,13 @@
       double smooth;
};

- struct line_pnts *Pnts;
- struct line_cats *Cats2;
- dbDriver *driver2;
- dbString sql2;
- struct Map_info Map2;
- struct field_info *ff;
- int count;
+extern struct line_pnts *Pnts;
+extern struct line_cats *Cats2;
+extern dbDriver *driver2;
+extern dbString sql2;
+extern struct Map_info Map2;
+extern struct field_info *ff;
+extern int count;

Not sure if it's right but now it compiles.

My suggestion is to use the following CFLAGS to catch such
problems:

export CFLAGS='-g -Wall -Werror-implicit-function-declaration -fno-common'
configure ...
make

Markus

11

Helena wrote:

I would like to remove the confusing dmax option (it adds points on contours if the given
points are farther appart than dmax) - please let me know if anybody needs it (I will
then keep it and try to better explain it).

Whithout dmax it will support only points as input? I think that contours as input can be useful. Is it a problem to keep it? Why is it confusing?

Radim

12

Radim Blazek wrote:

Helena wrote:
>
> I would like to remove the confusing dmax option (it adds points on
> contours if the given
> points are farther appart than dmax) - please let me know if anybody
> needs it (I will
> then keep it and try to better explain it).

Whithout dmax it will support only points as input? I think that
contours as input can be useful.

it will continue supporting contours - it was there just to add
additional
points on contours using 1D spline.

Is it a problem to keep it?

No

Why is it confusing?

adding points to contours often does not improve interpolation - just
the opposite,
especially if the contours are far appart. I have set the default in
such a way that
it is now practically switched off. I have found that people often
thought that it is doing
the same thing as dmin, setting it to a low value that added a huge
number of points.

I will keep it and I will try to describe it better and see whether we
will get
any users who have troubles with it.

Helena

Radim

13

On 12/13/04 2:02 AM, "Radim Blazek" <blazek@itc.it> wrote:

Benjamin Ducke wrote:

Hi there,
Here are some questions I need answered to make some more progress:

1. GUI:

If so, how does all the GRASS functionality contained in current GIS
Manager fit into qGIS? What about the Tk runtime forms (I thought they were
quite nice)?

I want to work on QGIS again after GRASS 6.0.0 release. I would like to
add some sort of easy to use GUI for GRASS modules, probably a
combination of description generated by module and predefined options
for each task. Suggestions are welcome.

Benjamin,

QGIS is nice looking and growing in functionality. There are versions for
both Windows and Mac that do not require X-Windows, but use native graphic
display drivers (e.g., Aqua for Mac). But qGIS is still in a comparatively
early state of development (version 0.5 is out and 0.6 is being developed).
Also, as Radim implies, there would need to be thoughtful revision of the
interface to accommodate all of GRASS functionality. Looking at the QGIS
website, it seems also that there are license issues QT for Windows. It is
not free software for Windows as it is for Mac and Linux. Currently, one
qGIS developer has a commercial QT license for Windows and is making Windows
binaries freely available under the terms of his commercial license.
Although this is highly laudable, it seems problematic in the long run. This
makes me worry a bit about QT as a platform for GRASS. Although I'm a Mac
person, there are a lot of Windows users out there. Recent changes in ESRI
licensing for Arc 9 may make GRASS even more attractive for Windows
users--if they have a useable version that is reasonably easy to install.

The tcltk interface has continued to evolve a lot over the past 9 months. It
is much better than it was a year ago. Tcltk is also free software and
available for all platforms on which GRASS runs. However, tcltk has its own
issues. It seems a bit quirky from a programming standpoints--sometimes not
interacting well with the C modules. Also, as it is now implemented, it
requries X-windows but some tcltk versions don't work with GRASS. This means
that the native Mac tcltk doesn't work without some tweaking. Windows
requires Cygwin and its Xwindows server, but GRASS doesn't work with Cygwin
tcltk. Tcltk 8.4 on Debian (I think) won't work and you have to have 8.3
installed too (or instead). I don't know if or whether these could be fixed
or whether version of Tcltk operate outside of an X-Windows environment if
that is desirable.

We definitely need to continue to develop and improve the GUI. Making it
more 'intelligent' from the user standpoint would be a big help form
something as complex as GRASS. JMP statistics package has a very interesting
approach to this kind of complexity that might be worth considering. I had
thought that QT might be a very good platform to build this in. However, the
problems with availability for Windows leaves me a little more hesitant
about this. I'm not cognizant of alternatives, however. Perhaps Radim could
speak to this more as he has been actively participating in the qGIS project
and did a lot with the Tcltk GUI.

Michael

____________________
C. Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

14

For QGIS+GRASS on Win there are 2 options:
1) GPL X11 version of QT 3 was ported to win32:
      http://kde-cygwin.sourceforge.net/qt3-win32/screenshots.php
      http://kde-cygwin.sourceforge.net/qt3-win32/qt3-win32/roadmap.php
    It seems that the QPrinter is the only missing class which is
    important for QGIS.
2) Do not link with GRASS library. Data can be read via GDAL.
    GUI for modules does not need to be linked with the GRASS library.
    The only problem is digitizing.

Note that GRASS currently does not run on windows without Cygwin, I am sure that QPrinter will be ready before a GRASS port to windows.

Radim

Michael Barton wrote:

On 12/13/04 2:02 AM, "Radim Blazek" <blazek@itc.it> wrote:

Benjamin Ducke wrote:

Hi there,
Here are some questions I need answered to make some more progress:

1. GUI:

If so, how does all the GRASS functionality contained in current GIS
Manager fit into qGIS? What about the Tk runtime forms (I thought they were
quite nice)?

I want to work on QGIS again after GRASS 6.0.0 release. I would like to
add some sort of easy to use GUI for GRASS modules, probably a
combination of description generated by module and predefined options
for each task. Suggestions are welcome.

Benjamin,

QGIS is nice looking and growing in functionality. There are versions for
both Windows and Mac that do not require X-Windows, but use native graphic
display drivers (e.g., Aqua for Mac). But qGIS is still in a comparatively
early state of development (version 0.5 is out and 0.6 is being developed).
Also, as Radim implies, there would need to be thoughtful revision of the
interface to accommodate all of GRASS functionality. Looking at the QGIS
website, it seems also that there are license issues QT for Windows. It is
not free software for Windows as it is for Mac and Linux. Currently, one
qGIS developer has a commercial QT license for Windows and is making Windows
binaries freely available under the terms of his commercial license.
Although this is highly laudable, it seems problematic in the long run. This
makes me worry a bit about QT as a platform for GRASS. Although I'm a Mac
person, there are a lot of Windows users out there. Recent changes in ESRI
licensing for Arc 9 may make GRASS even more attractive for Windows
users--if they have a useable version that is reasonably easy to install.

The tcltk interface has continued to evolve a lot over the past 9 months. It
is much better than it was a year ago. Tcltk is also free software and
available for all platforms on which GRASS runs. However, tcltk has its own
issues. It seems a bit quirky from a programming standpoints--sometimes not
interacting well with the C modules. Also, as it is now implemented, it
requries X-windows but some tcltk versions don't work with GRASS. This means
that the native Mac tcltk doesn't work without some tweaking. Windows
requires Cygwin and its Xwindows server, but GRASS doesn't work with Cygwin
tcltk. Tcltk 8.4 on Debian (I think) won't work and you have to have 8.3
installed too (or instead). I don't know if or whether these could be fixed
or whether version of Tcltk operate outside of an X-Windows environment if
that is desirable.

We definitely need to continue to develop and improve the GUI. Making it
more 'intelligent' from the user standpoint would be a big help form
something as complex as GRASS. JMP statistics package has a very interesting
approach to this kind of complexity that might be worth considering. I had
thought that QT might be a very good platform to build this in. However, the
problems with availability for Windows leaves me a little more hesitant
about this. I'm not cognizant of alternatives, however. Perhaps Radim could
speak to this more as he has been actively participating in the qGIS project
and did a lot with the Tcltk GUI.

Michael

____________________
C. Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

15

On Thu, December 16, 2004 10:43, Radim Blazek said:

For QGIS+GRASS on Win there are 2 options:
1) GPL X11 version of QT 3 was ported to win32:
      http://kde-cygwin.sourceforge.net/qt3-win32/screenshots.php
      http://kde-cygwin.sourceforge.net/qt3-win32/qt3-win32/roadmap.php
    It seems that the QPrinter is the only missing class which is
    important for QGIS.

This requires cygwin, or ?

2) Do not link with GRASS library. Data can be read via GDAL.
    GUI for modules does not need to be linked with the GRASS library.
    The only problem is digitizing.

I don't think the real problem is the linking issue (polluting the GPL), but
it is QGIS itself. What happens if the developer who has a commercial license
now, goes away ? No one can compile QGIS on MS Windows unless they have a
commercial license or they use cygwin...

Moritz

Note that GRASS currently does not run on windows without Cygwin, I am
sure that QPrinter will be ready before a GRASS port to windows.

Radim

Michael Barton wrote:

On 12/13/04 2:02 AM, "Radim Blazek" <blazek@itc.it> wrote:

Benjamin Ducke wrote:

Hi there,
Here are some questions I need answered to make some more progress:

1. GUI:

If so, how does all the GRASS functionality contained in current GIS
Manager fit into qGIS? What about the Tk runtime forms (I thought they were
quite nice)?

I want to work on QGIS again after GRASS 6.0.0 release. I would like to
add some sort of easy to use GUI for GRASS modules, probably a
combination of description generated by module and predefined options
for each task. Suggestions are welcome.

Benjamin,

QGIS is nice looking and growing in functionality. There are versions for
both Windows and Mac that do not require X-Windows, but use native graphic
display drivers (e.g., Aqua for Mac). But qGIS is still in a comparatively
early state of development (version 0.5 is out and 0.6 is being developed).
Also, as Radim implies, there would need to be thoughtful revision of the
interface to accommodate all of GRASS functionality. Looking at the QGIS
website, it seems also that there are license issues QT for Windows. It is
not free software for Windows as it is for Mac and Linux. Currently, one
qGIS developer has a commercial QT license for Windows and is making Windows
binaries freely available under the terms of his commercial license.
Although this is highly laudable, it seems problematic in the long run. This
makes me worry a bit about QT as a platform for GRASS. Although I'm a Mac
person, there are a lot of Windows users out there. Recent changes in ESRI
licensing for Arc 9 may make GRASS even more attractive for Windows
users--if they have a useable version that is reasonably easy to install.

The tcltk interface has continued to evolve a lot over the past 9 months. It
is much better than it was a year ago. Tcltk is also free software and
available for all platforms on which GRASS runs. However, tcltk has its own
issues. It seems a bit quirky from a programming standpoints--sometimes not
interacting well with the C modules. Also, as it is now implemented, it
requries X-windows but some tcltk versions don't work with GRASS. This means
that the native Mac tcltk doesn't work without some tweaking. Windows
requires Cygwin and its Xwindows server, but GRASS doesn't work with Cygwin
tcltk. Tcltk 8.4 on Debian (I think) won't work and you have to have 8.3
installed too (or instead). I don't know if or whether these could be fixed
or whether version of Tcltk operate outside of an X-Windows environment if
that is desirable.

We definitely need to continue to develop and improve the GUI. Making it
more 'intelligent' from the user standpoint would be a big help form
something as complex as GRASS. JMP statistics package has a very interesting
approach to this kind of complexity that might be worth considering. I had
thought that QT might be a very good platform to build this in. However, the
problems with availability for Windows leaves me a little more hesitant
about this. I'm not cognizant of alternatives, however. Perhaps Radim could
speak to this more as he has been actively participating in the qGIS project
and did a lot with the Tcltk GUI.

Michael

____________________
C. Michael Barton, Professor of Anthropology
School of Human Evolution and Social Change
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

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

16

Moritz Lennert wrote:

On Thu, December 16, 2004 10:43, Radim Blazek said:

For QGIS+GRASS on Win there are 2 options:
1) GPL X11 version of QT 3 was ported to win32:
     http://kde-cygwin.sourceforge.net/qt3-win32/screenshots.php
     http://kde-cygwin.sourceforge.net/qt3-win32/qt3-win32/roadmap.php
   It seems that the QPrinter is the only missing class which is
   important for QGIS.

This requires cygwin, or ?

No.

Radim

17

Hello Michael

On Wed, 15 Dec 2004, Michael Barton wrote:

approach to this kind of complexity that might be worth considering. I had
thought that QT might be a very good platform to build this in. However, the
problems with availability for Windows leaves me a little more hesitant
about this. I'm not cognizant of alternatives, however.

Any time this was discussed on the list before the consensus was to use gtk, although some people suggested wxWindows based on Python, but I found it was very difficult, nearly impossible to install (I gauge my opinion of packages on small things like it assuming the C++ compiler was the same as the C compiler with no way to change it, and it didn't inspire confidence!)

Starting from new, Gtk would probably be the best choice. But everything so far has been built on top of something else, i.e. the existing Tcl/Tk interface or QGIS which was already using Qt. So for historical reasons a non-optimal windowing toolkit has been used.

Paul