[GRASS5] Re: GRASS GUI and Qt

GRASS GIS GRASS GIS developer
1

Christian,

Thanks for your detailed comments. Sorry about taking awhile to get back to
you. For some reason, my spam filter ate your email. I think I've got that
fixed now--I hope.

There are a *lot* of good ideas here. I still think it's best to separate
for discussion a set of specs for a UI and the toolkit/platform with which
we implement it. This lets us focus first on how the UI should function and
look, without sweating over platforms. In fact, once the UI specs are worked
out, a platform choice may be obvious.

Once we settle on a set of specs, however--and I'd like us to be visionary
as long as it's realistic--then it *would* be nice to have a mock-up so that
everyone could get some idea of how GRASS could look to the user.

You make a good case for a separate render/display button. My reason for not
having it was 1) to keep the interface as simple as possible (fewer buttons)
and 2) to make it easier for beginning users to make GRASS work ('I've added
maps but I can't see anything'???). However, like you, I hate to have to
redraw a complex screen every time I change one thing. I'd rather do all the
changes, *then* render the result. Maybe some way to meet all these needs?

I don't quite understand what you are suggesting for a display
control/window structure. I was suggesting a single set of controls
(including menus, buttons, layer tree, other controls, and console) that
could operate different displays in different windows. This is the UI model
used in Idrisi and MapInfo. GIMP also uses a variant of this model (single
control/tool pallets, but menus for each display window). The ArcView/ArcGIS
model (also in Inkscape) has a complete set of menus, other controls like
buttons, and layer tree display for *each* display window open. I personally
find that this limits the size of the actual display area--especially if you
open multiple displays--and has a more 'cluttered' look. Nevertheless, we
should be able to have an independent layer tree for each display, so that
each display can more easily show different information. We may be saying
the same thing.

While there are lots of translation programs for graphics output, having
GRASS export to several very common formats makes life much easier for
users. One of GRASS's enormous advantages is its ability to read an
amazingly wide variety of formats. The same tools that make this possible
also make exporting into multiple formats trivial. No need to save in the
30+ formats that GRASS reads. But a user wants to be able to put the output
into another program for dissemination with a minimum of hassle.

Bob Covill has also been working on ideas for a new UI. He's done lots of
work on NVIZ, so he will have a lot valuable insights. Perhaps you, Bob, and
I should coordinate on this, with anyone else out there who'd like to get
involved. The UI development would be better as a team approach than just me
(or someone else) doing it, as it really needs diverse resources.

I've been stashing away all the responses to my call for comments on a UI
proposal. At some point--maybe in a few weeks--we might be able to collate
these and come up with a revised set of specs done up as an actual roadmap.
This would outline the order in which we would develop the UI (i.e., things
we can do sooner and those that would have to come later). Then we need to
see what platform will best do this. I'm pretty neutral about platform. I've
put a lot of sweat into TclTk over the past year and it's got some distinct
advantages as well as limitations. But I'm not tied to that platform. If
another would work better AND someone who knows it can take the UI
development lead, that's OK. I'm happy to help as I learn another platform
and maybe try to serve more as coordinator in such a case.

What do you think?

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: Christian Wygoda <crischan@wygoda.net>
Date: Mon, 07 Nov 2005 18:52:00 +0100
To: <grass5@grass.itc.it>
Subject: GRASS GUI and Qt

Hello everyone listening in,

I would like to speak in favor of a new GUI and in favour of a Qt-based one:

"Right now some of us are looking into options to build a new GUI for the
next versions of GRASS. Having started to develop one based on the Qt toolkit
I was happy to get some ideas. This prompted me to stop further coding on
Qgrass (the Qt Gui for GRASS).
In direct answer to Michel Barton¹s recent list of ideas I would like to
provide my thoughts.
First of all, Qt offers a robust set of libraries for GUI, database, i18n, XML
and much more. Most of the needs for a GUI can be satisfied using the Qt and
GRASS libs. We wouldn¹t need to introduce a lot of new dependencies (which
might also be true for other toolkits, I don¹t know).
I fully agree that the ability to have multiple monitors is great and should
not be given up. As for the question if the GUI should be integrated into one
monolithic window or split up into several ones ­ i should be up to the user.
Personally I am not too enthusiastic about having several windows for one
application as they always end up over each other. But maybe I¹m just a
³windows messy²... To make this an option for the user would be no problem at
all.
I would like to go a step further. We should have a workspace widget which
should provide a tabbed set of minitors (think like in Firefox for example)
and each monitor should also be detachable from the workspace to become a
single window. So even if we have a ³monolithic² GUI, individual monitors
could be individula windows. Or the workspace could be a individual window and
again individual monitors could also be individual windows!
Now for the monitor manager. Of course if we have multiple monitors, each
monitor should have it¹s own manager. These could be grouped or floated ­ just
like the monitors they control. For the manager itself Qt offers a great
Model/View architecture. Once one understands the programming needed to use
this (documentation for this is still a little bit example-orientated and the
examples aren¹t very demanding...) it provides a powerful way to abstract the
Layer model and provide a comfortable controller. Keeping the tree-like model
should be no question ­ having the option to disable (possibly nested) groups
of layers with one click is just superior. As having the top-most displayed
layer on top of the Layer model is common sense, I fully agree with Michael
that we should go with the flow here. (If anyone wants it it also could be an
option to flip the order around.) Doing auto-naming of layers if no override
is set should be part of the next generation GRASS GUI too.
Personally I think switching beetween 2D/2.5D display for a given Layer model
could be and should be only a mouse click (or keyboard shortcut) away. Though
I haven¹t go into Qt paint system Arthur to deep yet, I think it¹s builtin
transformation routines could be handy here... As for NVIz: Qt comes with a
OpenGL module to embed seamlessly into Qt applications.
Michael`s ideas on placing the buttons to do certain things sound robust. But
I disagree that we don¹t need a ³render² button: Though auto-rendering could
be an option, I would make it mandatory. I would like to stay in control when
he GUI is eatin up my CPU to render large layers... When I programmed QGrass
to make it display raster layers, I found that it is an neccessary approach to
distinguish between rendering and displaying an layer. I only render when the
user wants me to or I need to (let¹s say the GRASS window changed due to a
zoom or pan for example). When I hide a layer and unhide it again I check if
the last pixmap produced for displaying by the rendering routine is still
valid and just display it instead of doing a new render. So hiding/unhiding an
layer is very quick! What I want to say is that the user should stay in
control of the CPU-consuming actions like rendering. When I hit the render
button or zoom or pan I know that my CPU will need to work. For the actions
which come cheap CPU-time (like displaying a already rendered pixmap) they
should just happen. They are not going to do any harm. (This still doesn¹t
sound very clear, does it?)
Menus and the dialogs they offer acces to could be part of a GUI plugin system
for which Qt offers good base classes. Help should stay part of the GUI and in
a Qt GUI would be accessible trough Qt Assistant, Qt¹s help browser system.
Keeping GRASS scriptable is maybe the most important demand we have for a new
GUI. And here, Qt comes handy by having QSA. With QSA it is possible to make a
Qt/C++ application scriptable. Just what we need, isn¹t it?
Attribute management needs to be better accessible trough the GUI and I think
that Qt¹s SQL module is the right thing to achieve this. It provides an SQL
abstraction to easily display/edit SQL from different sources. Qt comes with
(optionally built) drivers to access PostgreSQL, MySQL, ODBC, DB2 and SqLite.
Own drivers can be implemented as plugins.
For printing and exporting I would be totally happy to have support for one
raster type (preferrably PNG) and one vecor type (preferrably SVG). There are
enough good tools to convert from these into whatever one may need. I have to
admit though that Qt4 right now lacks good SVG support. Qt3 had SVG support
and Qt4 offers it trough it¹s Qt3 compatibility classes, but they are not part
of the main distribution. But it is planned to introduce SVG support in one of
the next maintenance releases of Qt4.
We should also aim for an integrated shell widget. Then we could start the GUI
from outside a GRASS session ­ an concept more familiar to the classical
ArcGIS user. (The GUI would become the GIS in the mind of the user. This
raises the bar on which to measure if the GUI is done good!) One problem is
that we would need to write ou own shell widget ­ Qt doesn¹t come with one.
But maybe we could port KDE¹s konsole part, which is after all Qt based.

So we agree that we want a new, more intuitive GUI. It should be flexible and
as integrated or ³exploded² as the user wants it. The full power should be
available trough the GUI as well as from the shell. Attribute databases should
be really presented as part of the geographic information, just as is the
output on the monitor."

Please send in your comments. I may code a little mockup for the GUI and make
it available so that even the non-coders can see if Qt can do the things we
want and need.

Crischan

2

Hi everyone,

This discussion really make me itchy to help with the next generation
GUI for GRASS. Let`s talk on about the features we need. Adn please
don't mind if I tend to look for the Qt side of life. It's the toolkit I
have choosen a long time ago for my programming projects and has served
me well so far. I'll keep the Qt mockup up to date with this discussion,
time allowing. I can still use it as a good template for a complex GUI.

Christian,

Thanks for your detailed comments. Sorry about taking awhile
to get back to you. For some reason, my spam filter ate your
email. I think I've got that fixed now--I hope.

There are a *lot* of good ideas here. I still think it's best
to separate for discussion a set of specs for a UI and the
toolkit/platform with which we implement it. This lets us
focus first on how the UI should function and look, without
sweating over platforms. In fact, once the UI specs are
worked out, a platform choice may be obvious.

Once we settle on a set of specs, however--and I'd like us to
be visionary as long as it's realistic--then it *would* be
nice to have a mock-up so that everyone could get some idea
of how GRASS could look to the user.

You make a good case for a separate render/display button. My
reason for not having it was 1) to keep the interface as
simple as possible (fewer buttons) and 2) to make it easier
for beginning users to make GRASS work ('I've added maps but
I can't see anything'???). However, like you, I hate to have
to redraw a complex screen every time I change one thing. I'd
rather do all the changes, *then* render the result. Maybe
some way to meet all these needs?

I'm not sure if I have explained my render/paint philosophy right. Take
2:
First Manual Render Mode. There are three events which requires painting
of an layer:
- Widget paint events
- Manual Render events
- GRASS window change (zoom, pan)
Also, each layer has a state if it is current or not. GRASS window
change events set current=false, while render events set current=true.
Now a layer can be either
- Rendered and visible,
- Rendered but invisble,
- Not rendered but visible,
- Not rendered and not visible.
We can forget about the last state, as nothing ever happens with such a
layer...
(Visibility here means wether the layer is checked or unchecked in the
layer tree) Now what happens for each of the above events with layers in
each state? The following table explains. (Don`t mind the shortened
if-syntax from C)

              | Rendered/Visible | Rendered/Inv. | Not
Rendered/Visible
--------------+--------------------------+---------------+--------------
-------
Paint Event | Current ? Paint : Render | Nothing | Nothing
Manual Render | Current ? Paint : Render | Nothing | Render
GRASS Window | Render | Current=false | Nothing

This would minimze the number of render events and thus CPU usage.
Now for Auto Mode: The only difference would be that paint events
trigger manual render events and that adding a layer or changing some of
its style options would trigger a paint event.
The switch beetween the two modes could easily be done by checkable
button sitting in the GIS manager toolbar. What about that?

I don't quite understand what you are suggesting for a
display control/window structure. I was suggesting a single
set of controls (including menus, buttons, layer tree, other
controls, and console) that could operate different displays
in different windows. This is the UI model used in Idrisi and
MapInfo. GIMP also uses a variant of this model (single
control/tool pallets, but menus for each display window). The
ArcView/ArcGIS model (also in Inkscape) has a complete set of
menus, other controls like buttons, and layer tree display
for *each* display window open. I personally find that this
limits the size of the actual display area--especially if you
open multiple displays--and has a more 'cluttered' look.
Nevertheless, we should be able to have an independent layer
tree for each display, so that each display can more easily
show different information. We may be saying the same thing.

I think the next generation GUI shouldn`t limit itself to a rigid
structure. There are four common approaches for GUIs out there which I
see used in successful apps. Each user may has its preference and why
not give them the option to have different GUI philosphies in one
application?
The first GUI approach isn't really suited for us: Single Document
Interface (SDI). We want multiple monitors, so let's head straight into
Multiple Document Interface (MDI). I see three different approaches for
MDI:

* Tabbed windows: Like in Firefox. Common tools (GIS manager, SQL
browser, et cetera) would probably best be kept in dockable/floatable
toolboxes, which display the active monitor's information.
* MDI workspace: An central workspace holds multiple windows. This is
what ArcView/ArcGIS does. I would though take the GIS manager and so on
from each monitor window and keep them in dock-/floatable toolboxes like
in approach one.* Toplevel Child Windows: Each monitor would be a
toplevel window. Toolboxes would be float-/dockable toolboxes, ony that
now each monitor would have it's own set of toolboxes.

So while variant three makes it easy to distribute monitors onto several
desktops, the first two variants keep the GUI more together. For the
first two variants a nice feature would be to dettach single monitors
(and put them into toplevel mode with their own set of controls). Then
of course attaching would be logical reverse operation...

If you have any more ideas on general GUI modes throw them in. What do
you think about letting the user choose which GUI variant to use?

While there are lots of translation programs for graphics
output, having GRASS export to several very common formats
makes life much easier for users. One of GRASS's enormous
advantages is its ability to read an amazingly wide variety
of formats. The same tools that make this possible also make
exporting into multiple formats trivial. No need to save in the
30+ formats that GRASS reads. But a user wants to be able to put the
30+ output
into another program for dissemination with a minimum of hassle.

Well, GRASS itself uses external helper programs to read and write
formats, especially GDAL. Why not do the same for output (if we find a
suitable library...)? Then SVG and PNG export could be sufficent. A
proposal: SVG and PNG should really be built in. Other formats could be
added using plugins (over time).

Bob Covill has also been working on ideas for a new UI. He's
done lots of work on NVIZ, so he will have a lot valuable
insights. Perhaps you, Bob, and I should coordinate on this,
with anyone else out there who'd like to get involved. The UI
development would be better as a team approach than just me
(or someone else) doing it, as it really needs diverse resources.

It's nice to an NVIZ guy at hand. The only 3D graphics programming was
for a class years ago. The idea of calling 3D up from the 2D view is
very good and thus me need to have an easy integration of 2D and 3D
graphics in the toolkit - like in Qt... ;o)

I've been stashing away all the responses to my call for
comments on a UI proposal. At some point--maybe in a few
weeks--we might be able to collate these and come up with a
revised set of specs done up as an actual roadmap. This would
outline the order in which we would develop the UI (i.e.,
things we can do sooner and those that would have to come
later). Then we need to see what platform will best do this.
I'm pretty neutral about platform. I've put a lot of sweat
into TclTk over the past year and it's got some distinct
advantages as well as limitations. But I'm not tied to that
platform. If another would work better AND someone who knows
it can take the UI development lead, that's OK. I'm happy to
help as I learn another platform and maybe try to serve more
as coordinator in such a case.

Let's see what thoughts we can settle on and what conclusions we draw.
We might then start making a roadmap for the GUI. And then make the next
step. One after the other.

What do you think?

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

Crischan

3

Christian,

what are exactly your reasons to don't continue with QGIS.
I mean what do you think that cannot be done in QGIS?
Because most (all?) of the things you are talking about
is already there. Including printing in vector/raster formats
and GRASS shell.

Radim

> From: Christian Wygoda <crischan@wygoda.net>
> Date: Mon, 07 Nov 2005 18:52:00 +0100
> To: <grass5@grass.itc.it>
> Subject: GRASS GUI and Qt
>
> Hello everyone listening in,
>
> I would like to speak in favor of a new GUI and in favour of a Qt-based one:
>
> "Right now some of us are looking into options to build a new GUI for the
> next versions of GRASS. Having started to develop one based on the Qt toolkit
> I was happy to get some ideas. This prompted me to stop further coding on
> Qgrass (the Qt Gui for GRASS).
> In direct answer to Michel Barton¹s recent list of ideas I would like to
> provide my thoughts.
> First of all, Qt offers a robust set of libraries for GUI, database, i18n, XML
> and much more. Most of the needs for a GUI can be satisfied using the Qt and
> GRASS libs. We wouldn¹t need to introduce a lot of new dependencies (which
> might also be true for other toolkits, I don¹t know).
> I fully agree that the ability to have multiple monitors is great and should
> not be given up. As for the question if the GUI should be integrated into one
> monolithic window or split up into several ones ­ i should be up to the user.
> Personally I am not too enthusiastic about having several windows for one
> application as they always end up over each other. But maybe I¹m just a
> ³windows messy²... To make this an option for the user would be no problem at
> all.
> I would like to go a step further. We should have a workspace widget which
> should provide a tabbed set of minitors (think like in Firefox for example)
> and each monitor should also be detachable from the workspace to become a
> single window. So even if we have a ³monolithic² GUI, individual monitors
> could be individula windows. Or the workspace could be a individual window and
> again individual monitors could also be individual windows!
> Now for the monitor manager. Of course if we have multiple monitors, each
> monitor should have it¹s own manager. These could be grouped or floated ­ just
> like the monitors they control. For the manager itself Qt offers a great
> Model/View architecture. Once one understands the programming needed to use
> this (documentation for this is still a little bit example-orientated and the
> examples aren¹t very demanding...) it provides a powerful way to abstract the
> Layer model and provide a comfortable controller. Keeping the tree-like model
> should be no question ­ having the option to disable (possibly nested) groups
> of layers with one click is just superior. As having the top-most displayed
> layer on top of the Layer model is common sense, I fully agree with Michael
> that we should go with the flow here. (If anyone wants it it also could be an
> option to flip the order around.) Doing auto-naming of layers if no override
> is set should be part of the next generation GRASS GUI too.
> Personally I think switching beetween 2D/2.5D display for a given Layer model
> could be and should be only a mouse click (or keyboard shortcut) away. Though
> I haven¹t go into Qt paint system Arthur to deep yet, I think it¹s builtin
> transformation routines could be handy here... As for NVIz: Qt comes with a
> OpenGL module to embed seamlessly into Qt applications.
> Michael`s ideas on placing the buttons to do certain things sound robust. But
> I disagree that we don¹t need a ³render² button: Though auto-rendering could
> be an option, I would make it mandatory. I would like to stay in control when
> he GUI is eatin up my CPU to render large layers... When I programmed QGrass
> to make it display raster layers, I found that it is an neccessary approach to
> distinguish between rendering and displaying an layer. I only render when the
> user wants me to or I need to (let¹s say the GRASS window changed due to a
> zoom or pan for example). When I hide a layer and unhide it again I check if
> the last pixmap produced for displaying by the rendering routine is still
> valid and just display it instead of doing a new render. So hiding/unhiding an
> layer is very quick! What I want to say is that the user should stay in
> control of the CPU-consuming actions like rendering. When I hit the render
> button or zoom or pan I know that my CPU will need to work. For the actions
> which come cheap CPU-time (like displaying a already rendered pixmap) they
> should just happen. They are not going to do any harm. (This still doesn¹t
> sound very clear, does it?)
> Menus and the dialogs they offer acces to could be part of a GUI plugin system
> for which Qt offers good base classes. Help should stay part of the GUI and in
> a Qt GUI would be accessible trough Qt Assistant, Qt¹s help browser system.
> Keeping GRASS scriptable is maybe the most important demand we have for a new
> GUI. And here, Qt comes handy by having QSA. With QSA it is possible to make a
> Qt/C++ application scriptable. Just what we need, isn¹t it?
> Attribute management needs to be better accessible trough the GUI and I think
> that Qt¹s SQL module is the right thing to achieve this. It provides an SQL
> abstraction to easily display/edit SQL from different sources. Qt comes with
> (optionally built) drivers to access PostgreSQL, MySQL, ODBC, DB2 and SqLite.
> Own drivers can be implemented as plugins.
> For printing and exporting I would be totally happy to have support for one
> raster type (preferrably PNG) and one vecor type (preferrably SVG). There are
> enough good tools to convert from these into whatever one may need. I have to
> admit though that Qt4 right now lacks good SVG support. Qt3 had SVG support
> and Qt4 offers it trough it¹s Qt3 compatibility classes, but they are not part
> of the main distribution. But it is planned to introduce SVG support in one of
> the next maintenance releases of Qt4.
> We should also aim for an integrated shell widget. Then we could start the GUI
> from outside a GRASS session ­ an concept more familiar to the classical
> ArcGIS user. (The GUI would become the GIS in the mind of the user. This
> raises the bar on which to measure if the GUI is done good!) One problem is
> that we would need to write ou own shell widget ­ Qt doesn¹t come with one.
> But maybe we could port KDE¹s konsole part, which is after all Qt based.
>
> So we agree that we want a new, more intuitive GUI. It should be flexible and
> as integrated or ³exploded² as the user wants it. The full power should be
> available trough the GUI as well as from the shell. Attribute databases should
> be really presented as part of the geographic information, just as is the
> output on the monitor."
>
> Please send in your comments. I may code a little mockup for the GUI and make
> it available so that even the non-coders can see if Qt can do the things we
> want and need.
>
> Crischan

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

4

hello Radim,

I fully understand your point to further support the GRASS-QGIS implementation
but I can as well understand the other point of view to build (again) another
state-of-the art GRASS UI.
Of course the development could stop half-way, like some other UI approaches
and never really reaches the GRASS community but I think that is OpenSource
philosophy: a lot of (redundant) work produces a high diversity of
application aiming to do the same thing to give the user a choice.

However, I think the main point is, that Michael asked for ideas how an
optimal RS/GIS UI should look like. QGIS is great and I love to use it
instead of ArcView but personally I mainly use GRASS as substitute for
ERDAS/ENVI etc. and I am pretty much accustomed to multi-window usage.

There are also a lot of other ideas how an optimal UI for raster/vector
manipulation, visualisation etc. should look like. To summarise these ideas
and then start to design an UI, like Michael proposed is a good way, in my
opinion. Perhaps we will end up with a totally different UI than all the
proprietary ones but a more powerful/intuitive one.

I think that the QGIS vs. new QT/GTK GRASS UI does contradict each other. Many
people prefer the single-window setup like QGIS and others prefer the
opposite and at the end all users end up using the command line anyway. :wink:

Let's have a look how the "new" GRASS UI ideas develop,

best regards, Martin

On Monday 14 November 2005 10:52, Radim Blazek wrote:

Christian,

what are exactly your reasons to don't continue with QGIS.
I mean what do you think that cannot be done in QGIS?
Because most (all?) of the things you are talking about
is already there. Including printing in vector/raster formats
and GRASS shell.

Radim

> > From: Christian Wygoda <crischan@wygoda.net>
> > Date: Mon, 07 Nov 2005 18:52:00 +0100
> > To: <grass5@grass.itc.it>
> > Subject: GRASS GUI and Qt
> >
> > Hello everyone listening in,
> >
> > I would like to speak in favor of a new GUI and in favour of a Qt-based
> > one:
> >
> > "Right now some of us are looking into options to build a new GUI for
> > the next versions of GRASS. Having started to develop one based on the
> > Qt toolkit I was happy to get some ideas. This prompted me to stop
> > further coding on Qgrass (the Qt Gui for GRASS).
> > In direct answer to Michel Barton¹s recent list of ideas I would like
> > to provide my thoughts.
> > First of all, Qt offers a robust set of libraries for GUI, database,
> > i18n, XML and much more. Most of the needs for a GUI can be satisfied
> > using the Qt and GRASS libs. We wouldn¹t need to introduce a lot of new
> > dependencies (which might also be true for other toolkits, I don¹t
> > know).
> > I fully agree that the ability to have multiple monitors is great and
> > should not be given up. As for the question if the GUI should be
> > integrated into one monolithic window or split up into several ones ­ i
> > should be up to the user. Personally I am not too enthusiastic about
> > having several windows for one application as they always end up over
> > each other. But maybe I¹m just a ³windows messy²... To make this an
> > option for the user would be no problem at all.
> > I would like to go a step further. We should have a workspace widget
> > which should provide a tabbed set of minitors (think like in Firefox
> > for example) and each monitor should also be detachable from the
> > workspace to become a single window. So even if we have a ³monolithic²
> > GUI, individual monitors could be individula windows. Or the workspace
> > could be a individual window and again individual monitors could also
> > be individual windows!
> > Now for the monitor manager. Of course if we have multiple monitors,
> > each monitor should have it¹s own manager. These could be grouped or
> > floated ­ just like the monitors they control. For the manager itself
> > Qt offers a great Model/View architecture. Once one understands the
> > programming needed to use this (documentation for this is still a
> > little bit example-orientated and the examples aren¹t very
> > demanding...) it provides a powerful way to abstract the Layer model
> > and provide a comfortable controller. Keeping the tree-like model
> > should be no question ­ having the option to disable (possibly nested)
> > groups of layers with one click is just superior. As having the
> > top-most displayed layer on top of the Layer model is common sense, I
> > fully agree with Michael that we should go with the flow here. (If
> > anyone wants it it also could be an option to flip the order around.)
> > Doing auto-naming of layers if no override is set should be part of the
> > next generation GRASS GUI too.
> > Personally I think switching beetween 2D/2.5D display for a given Layer
> > model could be and should be only a mouse click (or keyboard shortcut)
> > away. Though I haven¹t go into Qt paint system Arthur to deep yet, I
> > think it¹s builtin transformation routines could be handy here... As
> > for NVIz: Qt comes with a OpenGL module to embed seamlessly into Qt
> > applications.
> > Michael`s ideas on placing the buttons to do certain things sound
> > robust. But I disagree that we don¹t need a ³render² button: Though
> > auto-rendering could be an option, I would make it mandatory. I would
> > like to stay in control when he GUI is eatin up my CPU to render large
> > layers... When I programmed QGrass to make it display raster layers, I
> > found that it is an neccessary approach to distinguish between
> > rendering and displaying an layer. I only render when the user wants me
> > to or I need to (let¹s say the GRASS window changed due to a zoom or
> > pan for example). When I hide a layer and unhide it again I check if
> > the last pixmap produced for displaying by the rendering routine is
> > still valid and just display it instead of doing a new render. So
> > hiding/unhiding an layer is very quick! What I want to say is that the
> > user should stay in control of the CPU-consuming actions like
> > rendering. When I hit the render button or zoom or pan I know that my
> > CPU will need to work. For the actions which come cheap CPU-time (like
> > displaying a already rendered pixmap) they should just happen. They are
> > not going to do any harm. (This still doesn¹t sound very clear, does
> > it?)
> > Menus and the dialogs they offer acces to could be part of a GUI plugin
> > system for which Qt offers good base classes. Help should stay part of
> > the GUI and in a Qt GUI would be accessible trough Qt Assistant, Qt¹s
> > help browser system. Keeping GRASS scriptable is maybe the most
> > important demand we have for a new GUI. And here, Qt comes handy by
> > having QSA. With QSA it is possible to make a Qt/C++ application
> > scriptable. Just what we need, isn¹t it?
> > Attribute management needs to be better accessible trough the GUI and I
> > think that Qt¹s SQL module is the right thing to achieve this. It
> > provides an SQL abstraction to easily display/edit SQL from different
> > sources. Qt comes with (optionally built) drivers to access PostgreSQL,
> > MySQL, ODBC, DB2 and SqLite. Own drivers can be implemented as plugins.
> > For printing and exporting I would be totally happy to have support for
> > one raster type (preferrably PNG) and one vecor type (preferrably SVG).
> > There are enough good tools to convert from these into whatever one may
> > need. I have to admit though that Qt4 right now lacks good SVG support.
> > Qt3 had SVG support and Qt4 offers it trough it¹s Qt3 compatibility
> > classes, but they are not part of the main distribution. But it is
> > planned to introduce SVG support in one of the next maintenance
> > releases of Qt4.
> > We should also aim for an integrated shell widget. Then we could start
> > the GUI from outside a GRASS session ­ an concept more familiar to the
> > classical ArcGIS user. (The GUI would become the GIS in the mind of the
> > user. This raises the bar on which to measure if the GUI is done good!)
> > One problem is that we would need to write ou own shell widget ­ Qt
> > doesn¹t come with one. But maybe we could port KDE¹s konsole part,
> > which is after all Qt based.
> >
> > So we agree that we want a new, more intuitive GUI. It should be
> > flexible and as integrated or ³exploded² as the user wants it. The full
> > power should be available trough the GUI as well as from the shell.
> > Attribute databases should be really presented as part of the
> > geographic information, just as is the output on the monitor."
> >
> > Please send in your comments. I may code a little mockup for the GUI
> > and make it available so that even the non-coders can see if Qt can do
> > the things we want and need.
> >
> > Crischan
>
> _______________________________________________
> grass5 mailing list
> grass5@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5

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

--
Martin Wegmann

DLR - German Aerospace Center
German Remote Sensing Data Center
@
Dept.of Geography
Remote Sensing and Biodiversity Unit
&&
Dept. of Animal Ecology and Tropical Biology
University of Wuerzburg
Am Hubland
97074 Würzburg

phone: +49-(0)931 - 888 4797
mobile: +49-(0)175 2091725
fax: +49-(0)931 - 888 4961
http://www.biota-africa.org
http://www.biogis.de

5

Hi,

I don't want to stop development of any other GUI (even they probably
die like the others: GRASSQt, GTK GRASS, JGRASS), but yes
it is bad to fragment effort in so small comunity like GRASS.

I agree that it is good to separate design of GUI from technical aspects like
toolkit etc. But if you say that you need multiple windows which
are not in QGIS and so a new GUI must be developed I cannot agree.
It may be 2% of current QGIS code to enable multiple windows.
So my conclusion is that it is better to write those 2% instead of
start from scratch new 100% and stop on 20% because of lack of
developers.

I think that we have to get some new ideas for QGIS (or other GUI)
but I haven't seen anything like that in the mails. For example
I feel that the interface should be more workflow oriented
but I dont know how to do it. For now I want to develop
all the obvious things in QGIS and hopefully some new ideas appear
on top of that.

Radim

On 11/14/05, Martin Wegmann <wegmann@biozentrum.uni-wuerzburg.de> wrote:

hello Radim,

I fully understand your point to further support the GRASS-QGIS implementation
but I can as well understand the other point of view to build (again) another
state-of-the art GRASS UI.
Of course the development could stop half-way, like some other UI approaches
and never really reaches the GRASS community but I think that is OpenSource
philosophy: a lot of (redundant) work produces a high diversity of
application aiming to do the same thing to give the user a choice.

However, I think the main point is, that Michael asked for ideas how an
optimal RS/GIS UI should look like. QGIS is great and I love to use it
instead of ArcView but personally I mainly use GRASS as substitute for
ERDAS/ENVI etc. and I am pretty much accustomed to multi-window usage.

There are also a lot of other ideas how an optimal UI for raster/vector
manipulation, visualisation etc. should look like. To summarise these ideas
and then start to design an UI, like Michael proposed is a good way, in my
opinion. Perhaps we will end up with a totally different UI than all the
proprietary ones but a more powerful/intuitive one.

I think that the QGIS vs. new QT/GTK GRASS UI does contradict each other. Many
people prefer the single-window setup like QGIS and others prefer the
opposite and at the end all users end up using the command line anyway. :wink:

Let's have a look how the "new" GRASS UI ideas develop,

best regards, Martin

On Monday 14 November 2005 10:52, Radim Blazek wrote:
> Christian,
>
> what are exactly your reasons to don't continue with QGIS.
> I mean what do you think that cannot be done in QGIS?
> Because most (all?) of the things you are talking about
> is already there. Including printing in vector/raster formats
> and GRASS shell.
>
> Radim
>
> > > From: Christian Wygoda <crischan@wygoda.net>
> > > Date: Mon, 07 Nov 2005 18:52:00 +0100
> > > To: <grass5@grass.itc.it>
> > > Subject: GRASS GUI and Qt
> > >
> > > Hello everyone listening in,
> > >
> > > I would like to speak in favor of a new GUI and in favour of a Qt-based
> > > one:
> > >
> > > "Right now some of us are looking into options to build a new GUI for
> > > the next versions of GRASS. Having started to develop one based on the
> > > Qt toolkit I was happy to get some ideas. This prompted me to stop
> > > further coding on Qgrass (the Qt Gui for GRASS).
> > > In direct answer to Michel Barton¹s recent list of ideas I would like
> > > to provide my thoughts.
> > > First of all, Qt offers a robust set of libraries for GUI, database,
> > > i18n, XML and much more. Most of the needs for a GUI can be satisfied
> > > using the Qt and GRASS libs. We wouldn¹t need to introduce a lot of new
> > > dependencies (which might also be true for other toolkits, I don¹t
> > > know).
> > > I fully agree that the ability to have multiple monitors is great and
> > > should not be given up. As for the question if the GUI should be
> > > integrated into one monolithic window or split up into several ones ­ i
> > > should be up to the user. Personally I am not too enthusiastic about
> > > having several windows for one application as they always end up over
> > > each other. But maybe I¹m just a ³windows messy²... To make this an
> > > option for the user would be no problem at all.
> > > I would like to go a step further. We should have a workspace widget
> > > which should provide a tabbed set of minitors (think like in Firefox
> > > for example) and each monitor should also be detachable from the
> > > workspace to become a single window. So even if we have a ³monolithic²
> > > GUI, individual monitors could be individula windows. Or the workspace
> > > could be a individual window and again individual monitors could also
> > > be individual windows!
> > > Now for the monitor manager. Of course if we have multiple monitors,
> > > each monitor should have it¹s own manager. These could be grouped or
> > > floated ­ just like the monitors they control. For the manager itself
> > > Qt offers a great Model/View architecture. Once one understands the
> > > programming needed to use this (documentation for this is still a
> > > little bit example-orientated and the examples aren¹t very
> > > demanding...) it provides a powerful way to abstract the Layer model
> > > and provide a comfortable controller. Keeping the tree-like model
> > > should be no question ­ having the option to disable (possibly nested)
> > > groups of layers with one click is just superior. As having the
> > > top-most displayed layer on top of the Layer model is common sense, I
> > > fully agree with Michael that we should go with the flow here. (If
> > > anyone wants it it also could be an option to flip the order around.)
> > > Doing auto-naming of layers if no override is set should be part of the
> > > next generation GRASS GUI too.
> > > Personally I think switching beetween 2D/2.5D display for a given Layer
> > > model could be and should be only a mouse click (or keyboard shortcut)
> > > away. Though I haven¹t go into Qt paint system Arthur to deep yet, I
> > > think it¹s builtin transformation routines could be handy here... As
> > > for NVIz: Qt comes with a OpenGL module to embed seamlessly into Qt
> > > applications.
> > > Michael`s ideas on placing the buttons to do certain things sound
> > > robust. But I disagree that we don¹t need a ³render² button: Though
> > > auto-rendering could be an option, I would make it mandatory. I would
> > > like to stay in control when he GUI is eatin up my CPU to render large
> > > layers... When I programmed QGrass to make it display raster layers, I
> > > found that it is an neccessary approach to distinguish between
> > > rendering and displaying an layer. I only render when the user wants me
> > > to or I need to (let¹s say the GRASS window changed due to a zoom or
> > > pan for example). When I hide a layer and unhide it again I check if
> > > the last pixmap produced for displaying by the rendering routine is
> > > still valid and just display it instead of doing a new render. So
> > > hiding/unhiding an layer is very quick! What I want to say is that the
> > > user should stay in control of the CPU-consuming actions like
> > > rendering. When I hit the render button or zoom or pan I know that my
> > > CPU will need to work. For the actions which come cheap CPU-time (like
> > > displaying a already rendered pixmap) they should just happen. They are
> > > not going to do any harm. (This still doesn¹t sound very clear, does
> > > it?)
> > > Menus and the dialogs they offer acces to could be part of a GUI plugin
> > > system for which Qt offers good base classes. Help should stay part of
> > > the GUI and in a Qt GUI would be accessible trough Qt Assistant, Qt¹s
> > > help browser system. Keeping GRASS scriptable is maybe the most
> > > important demand we have for a new GUI. And here, Qt comes handy by
> > > having QSA. With QSA it is possible to make a Qt/C++ application
> > > scriptable. Just what we need, isn¹t it?
> > > Attribute management needs to be better accessible trough the GUI and I
> > > think that Qt¹s SQL module is the right thing to achieve this. It
> > > provides an SQL abstraction to easily display/edit SQL from different
> > > sources. Qt comes with (optionally built) drivers to access PostgreSQL,
> > > MySQL, ODBC, DB2 and SqLite. Own drivers can be implemented as plugins.
> > > For printing and exporting I would be totally happy to have support for
> > > one raster type (preferrably PNG) and one vecor type (preferrably SVG).
> > > There are enough good tools to convert from these into whatever one may
> > > need. I have to admit though that Qt4 right now lacks good SVG support.
> > > Qt3 had SVG support and Qt4 offers it trough it¹s Qt3 compatibility
> > > classes, but they are not part of the main distribution. But it is
> > > planned to introduce SVG support in one of the next maintenance
> > > releases of Qt4.
> > > We should also aim for an integrated shell widget. Then we could start
> > > the GUI from outside a GRASS session ­ an concept more familiar to the
> > > classical ArcGIS user. (The GUI would become the GIS in the mind of the
> > > user. This raises the bar on which to measure if the GUI is done good!)
> > > One problem is that we would need to write ou own shell widget ­ Qt
> > > doesn¹t come with one. But maybe we could port KDE¹s konsole part,
> > > which is after all Qt based.
> > >
> > > So we agree that we want a new, more intuitive GUI. It should be
> > > flexible and as integrated or ³exploded² as the user wants it. The full
> > > power should be available trough the GUI as well as from the shell.
> > > Attribute databases should be really presented as part of the
> > > geographic information, just as is the output on the monitor."
> > >
> > > Please send in your comments. I may code a little mockup for the GUI
> > > and make it available so that even the non-coders can see if Qt can do
> > > the things we want and need.
> > >
> > > Crischan
> >
> > _______________________________________________
> > grass5 mailing list
> > grass5@grass.itc.it
> > http://grass.itc.it/mailman/listinfo/grass5
>
> _______________________________________________
> grass5 mailing list
> grass5@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5

--
Martin Wegmann

DLR - German Aerospace Center
German Remote Sensing Data Center
@
Dept.of Geography
Remote Sensing and Biodiversity Unit
&&
Dept. of Animal Ecology and Tropical Biology
University of Wuerzburg
Am Hubland
97074 Würzburg

phone: +49-(0)931 - 888 4797
mobile: +49-(0)175 2091725
fax: +49-(0)931 - 888 4961
http://www.biota-africa.org
http://www.biogis.de

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

6

Hi,

IMHO keeping GRASS as GUI-less engine and having QGIS as GRASS GUI is
not a bad idea, but what will say qgis developers/users on this - they
app will become a frontend to grass. If we head this way, qgis
developers alsou shuld be invited to this discussion.

And if we talk about fragmentation of OS. I cannot understand why we
have a lots of OS GIS related apps that can do some things and in some
areas fail but we havent one killer app. Having 3 or more flavors of
GRASS GUI is same => at the end ESRI wins.

just my 2c to flamefest.
Maris.

2005/11/14, Radim Blazek <radim.blazek@gmail.com>:

Hi,

I don't want to stop development of any other GUI (even they probably
die like the others: GRASSQt, GTK GRASS, JGRASS), but yes
it is bad to fragment effort in so small comunity like GRASS.

I agree that it is good to separate design of GUI from technical aspects like
toolkit etc. But if you say that you need multiple windows which
are not in QGIS and so a new GUI must be developed I cannot agree.
It may be 2% of current QGIS code to enable multiple windows.
So my conclusion is that it is better to write those 2% instead of
start from scratch new 100% and stop on 20% because of lack of
developers.

I think that we have to get some new ideas for QGIS (or other GUI)
but I haven't seen anything like that in the mails. For example
I feel that the interface should be more workflow oriented
but I dont know how to do it. For now I want to develop
all the obvious things in QGIS and hopefully some new ideas appear
on top of that.

Radim

7

Hello Māris,

On Mon, 14 Nov 2005 16:36:25 +0200 Māris Nartišs <maris.gis@gmail.com>
wrote:

Hi,

IMHO keeping GRASS as GUI-less engine and having QGIS as GRASS GUI is
not a bad idea, but what will say qgis developers/users on this - they
app will become a frontend to grass. If we head this way, qgis
developers alsou shuld be invited to this discussion.

And if we talk about fragmentation of OS. I cannot understand why we
have a lots of OS GIS related apps that can do some things and in some
areas fail but we havent one killer app. Having 3 or more flavors of
GRASS GUI is same => at the end ESRI wins.

Following the thread a while now I would like to through in some
euro-cents of mine as well...

I really like the QGIS-GRASS-integration and in my eyes this should be
the focus of the GRASS-gui. It is _so_ easy adding new commands to the
GRASS toolbox and I really like to thank Radim for his work on this
topic!

So, please, let us focus the main work on pushing QGIS as a GRASS-UI
and not reinventing yet another GUI.

The more userinput for improving the current QGIS-GRASS-integration
the better it will become.

just my 0.02¢.

  Stephan

--
GDF Hannover - Solutions for spatial data analysis and remote sensing
Hannover Office - Mengendamm 16d - D-30177 Hannover
Internet: www.gdf-hannover.de - Email: holl@gdf-hannover.de
Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508

8

Radim,

Some of what you mention here is why it seems a good idea to first focus on
what we want in a UI and then decide how to carry it out.

When we get to that second stage, I quite agree with you that it would be a
good idea to look at the QGIS code, especially if QT seems to be the best
platform--if for no other reason than it is an active, open source code for
a very functional GIS, that can read and manipulate GRASS files. Part of the
beauty of open source is that people can broadly share aspects of code
across different projects so that we can avoid having to start from scratch.
This is much like how modern science operates and a reason that it has been
successful in many respects.

QGIS is clearly a very good and accessible example of how QT can serve as a
UI platform for a modern GIS.

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

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Radim Blazek <radim.blazek@gmail.com>
Date: Mon, 14 Nov 2005 12:17:18 +0100
To: <wegmann@biozentrum.uni-wuerzburg.de>
Cc: <grass5@grass.itc.it>, Christian Wygoda <crischan@wygoda.net>
Subject: Re: [GRASS5] Re: GRASS GUI and Qt

Hi,

I don't want to stop development of any other GUI (even they probably
die like the others: GRASSQt, GTK GRASS, JGRASS), but yes
it is bad to fragment effort in so small comunity like GRASS.

I agree that it is good to separate design of GUI from technical aspects like
toolkit etc. But if you say that you need multiple windows which
are not in QGIS and so a new GUI must be developed I cannot agree.
It may be 2% of current QGIS code to enable multiple windows.
So my conclusion is that it is better to write those 2% instead of
start from scratch new 100% and stop on 20% because of lack of
developers.

I think that we have to get some new ideas for QGIS (or other GUI)
but I haven't seen anything like that in the mails. For example
I feel that the interface should be more workflow oriented
but I dont know how to do it. For now I want to develop
all the obvious things in QGIS and hopefully some new ideas appear
on top of that.

Radim

On 11/14/05, Martin Wegmann <wegmann@biozentrum.uni-wuerzburg.de> wrote:

hello Radim,

I fully understand your point to further support the GRASS-QGIS
implementation
but I can as well understand the other point of view to build (again) another
state-of-the art GRASS UI.
Of course the development could stop half-way, like some other UI approaches
and never really reaches the GRASS community but I think that is OpenSource
philosophy: a lot of (redundant) work produces a high diversity of
application aiming to do the same thing to give the user a choice.

However, I think the main point is, that Michael asked for ideas how an
optimal RS/GIS UI should look like. QGIS is great and I love to use it
instead of ArcView but personally I mainly use GRASS as substitute for
ERDAS/ENVI etc. and I am pretty much accustomed to multi-window usage.

There are also a lot of other ideas how an optimal UI for raster/vector
manipulation, visualisation etc. should look like. To summarise these ideas
and then start to design an UI, like Michael proposed is a good way, in my
opinion. Perhaps we will end up with a totally different UI than all the
proprietary ones but a more powerful/intuitive one.

I think that the QGIS vs. new QT/GTK GRASS UI does contradict each other.
Many
people prefer the single-window setup like QGIS and others prefer the
opposite and at the end all users end up using the command line anyway. :wink:

Let's have a look how the "new" GRASS UI ideas develop,

best regards, Martin

On Monday 14 November 2005 10:52, Radim Blazek wrote:

Christian,

what are exactly your reasons to don't continue with QGIS.
I mean what do you think that cannot be done in QGIS?
Because most (all?) of the things you are talking about
is already there. Including printing in vector/raster formats
and GRASS shell.

Radim

From: Christian Wygoda <crischan@wygoda.net>
Date: Mon, 07 Nov 2005 18:52:00 +0100
To: <grass5@grass.itc.it>
Subject: GRASS GUI and Qt

Hello everyone listening in,

I would like to speak in favor of a new GUI and in favour of a Qt-based
one:

"Right now some of us are looking into options to build a new GUI for
the next versions of GRASS. Having started to develop one based on the
Qt toolkit I was happy to get some ideas. This prompted me to stop
further coding on Qgrass (the Qt Gui for GRASS).
In direct answer to Michel Barton¹s recent list of ideas I would like
to provide my thoughts.
First of all, Qt offers a robust set of libraries for GUI, database,
i18n, XML and much more. Most of the needs for a GUI can be satisfied
using the Qt and GRASS libs. We wouldn¹t need to introduce a lot of new
dependencies (which might also be true for other toolkits, I don¹t
know).
I fully agree that the ability to have multiple monitors is great and
should not be given up. As for the question if the GUI should be
integrated into one monolithic window or split up into several ones ­ i
should be up to the user. Personally I am not too enthusiastic about
having several windows for one application as they always end up over
each other. But maybe I¹m just a ³windows messy²... To make this an
option for the user would be no problem at all.
I would like to go a step further. We should have a workspace widget
which should provide a tabbed set of minitors (think like in Firefox
for example) and each monitor should also be detachable from the
workspace to become a single window. So even if we have a ³monolithic²
GUI, individual monitors could be individula windows. Or the workspace
could be a individual window and again individual monitors could also
be individual windows!
Now for the monitor manager. Of course if we have multiple monitors,
each monitor should have it¹s own manager. These could be grouped or
floated ­ just like the monitors they control. For the manager itself
Qt offers a great Model/View architecture. Once one understands the
programming needed to use this (documentation for this is still a
little bit example-orientated and the examples aren¹t very
demanding...) it provides a powerful way to abstract the Layer model
and provide a comfortable controller. Keeping the tree-like model
should be no question ­ having the option to disable (possibly nested)
groups of layers with one click is just superior. As having the
top-most displayed layer on top of the Layer model is common sense, I
fully agree with Michael that we should go with the flow here. (If
anyone wants it it also could be an option to flip the order around.)
Doing auto-naming of layers if no override is set should be part of the
next generation GRASS GUI too.
Personally I think switching beetween 2D/2.5D display for a given Layer
model could be and should be only a mouse click (or keyboard shortcut)
away. Though I haven¹t go into Qt paint system Arthur to deep yet, I
think it¹s builtin transformation routines could be handy here... As
for NVIz: Qt comes with a OpenGL module to embed seamlessly into Qt
applications.
Michael`s ideas on placing the buttons to do certain things sound
robust. But I disagree that we don¹t need a ³render² button: Though
auto-rendering could be an option, I would make it mandatory. I would
like to stay in control when he GUI is eatin up my CPU to render large
layers... When I programmed QGrass to make it display raster layers, I
found that it is an neccessary approach to distinguish between
rendering and displaying an layer. I only render when the user wants me
to or I need to (let¹s say the GRASS window changed due to a zoom or
pan for example). When I hide a layer and unhide it again I check if
the last pixmap produced for displaying by the rendering routine is
still valid and just display it instead of doing a new render. So
hiding/unhiding an layer is very quick! What I want to say is that the
user should stay in control of the CPU-consuming actions like
rendering. When I hit the render button or zoom or pan I know that my
CPU will need to work. For the actions which come cheap CPU-time (like
displaying a already rendered pixmap) they should just happen. They are
not going to do any harm. (This still doesn¹t sound very clear, does
it?)
Menus and the dialogs they offer acces to could be part of a GUI plugin
system for which Qt offers good base classes. Help should stay part of
the GUI and in a Qt GUI would be accessible trough Qt Assistant, Qt¹s
help browser system. Keeping GRASS scriptable is maybe the most
important demand we have for a new GUI. And here, Qt comes handy by
having QSA. With QSA it is possible to make a Qt/C++ application
scriptable. Just what we need, isn¹t it?
Attribute management needs to be better accessible trough the GUI and I
think that Qt¹s SQL module is the right thing to achieve this. It
provides an SQL abstraction to easily display/edit SQL from different
sources. Qt comes with (optionally built) drivers to access PostgreSQL,
MySQL, ODBC, DB2 and SqLite. Own drivers can be implemented as plugins.
For printing and exporting I would be totally happy to have support for
one raster type (preferrably PNG) and one vecor type (preferrably SVG).
There are enough good tools to convert from these into whatever one may
need. I have to admit though that Qt4 right now lacks good SVG support.
Qt3 had SVG support and Qt4 offers it trough it¹s Qt3 compatibility
classes, but they are not part of the main distribution. But it is
planned to introduce SVG support in one of the next maintenance
releases of Qt4.
We should also aim for an integrated shell widget. Then we could start
the GUI from outside a GRASS session ­ an concept more familiar to the
classical ArcGIS user. (The GUI would become the GIS in the mind of the
user. This raises the bar on which to measure if the GUI is done good!)
One problem is that we would need to write ou own shell widget ­ Qt
doesn¹t come with one. But maybe we could port KDE¹s konsole part,
which is after all Qt based.

So we agree that we want a new, more intuitive GUI. It should be
flexible and as integrated or ³exploded² as the user wants it. The full
power should be available trough the GUI as well as from the shell.
Attribute databases should be really presented as part of the
geographic information, just as is the output on the monitor."

Please send in your comments. I may code a little mockup for the GUI
and make it available so that even the non-coders can see if Qt can do
the things we want and need.

Crischan

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

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

--
Martin Wegmann

DLR - German Aerospace Center
German Remote Sensing Data Center
@
Dept.of Geography
Remote Sensing and Biodiversity Unit
&&
Dept. of Animal Ecology and Tropical Biology
University of Wuerzburg
Am Hubland
97074 Würzburg

phone: +49-(0)931 - 888 4797
mobile: +49-(0)175 2091725
fax: +49-(0)931 - 888 4961
http://www.biota-africa.org
http://www.biogis.de

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

9

A proposal: SVG and PNG should really be built in. Other formats could
be added using plugins (over time).

FWIW, we already have a PNG(/PPM) driver.

d.mon start=PNG
d.*
d.mon stop=PNG

Michael is already using the netpbm tools in d.out.file to convert that
PNG (or PPM) output to other raster formats.

The idea of calling 3D up from the 2D view is very good and thus me
need to have an easy integration of 2D and 3D graphics in the toolkit

You might install GRASS 5.4 and try playing with the d.3d module.

Hamish

10

This is a general set of questions to people who have said very positive
things about QGIS. I just picked Stephan's post because it was the last of
the series that I've received so far.

What would be most helpful is for people to try to think about what it is
that they like about QGIS. That is, which GUI features seem to be most
appealing; which could be improved and how? This is not intended as seeking
a set of improvements to QGIS. Those comments should go to the QGIS list.
However, in order to come up with UI specs for GRASS, it would be good to
know what anyone finds especially great about the interface of ANY GIS
package out there. For example, do you just love having the layer display
attached to the side of every display window? I don't, but I'm sure that
some people do. Along these same lines, most of you have some experience
with ESRI products. But does anyone out there have experience with Idrisi or
other GIS software, and have encountered some interface features that they
feel are especially great (or absolutely appalling)?

The second item is something of a commentary of why QGIS cannot become THE
GRASS UI, but is ultimately related to the initial set of questions. Please
read on to the not so bitter end. This has nothing to do with the quality of
QGIS but is more of an issue of pragmatics. QGIS could become the _basis_
for a GRASS interface, but could not become THE GRASS interface without
changing so that it is no longer QGIS.

The reality is that GRASS is a very complex program. In an ongoing thread
about ESRI vs. GRASS, GRASS has been compared with ArcInfo and quite
rightly. In order to put all that complexity into a GUI, it is necessary to
pack a lot into nested menus, multiple buttons, and other interface
tools--including some new ones that may not be used yet. Case in point.
GRASS 5.3 had nearly 400 commands. I know because I coded them all into the
old tcltkgrass 5.3 menu system. In GRASS 6.1, we've trimmed that to a sparse
320. We cannot put all those commands into Radim's very attractive GRASS
tool-box. To make it work, we'd have to rearrange the toolbox, embed most of
the commands into a newly designed menu, add more buttons, etc. We'd either
have to get rid of some of the existing QGIS commands that are not GRASS
related or incorporate them also into an even more complex UI system. This
could be done, but the result would not the the QGIS of today, but an
interface that resembled QGIS in some way.

Furthermore, to simply use QGIS without changing anything else, we'd have
part of the UI organized around QT, many commands without a unified GUI to
call them, modules run from the command line in TclTk, NVIZ in a hybrid
TclTk/C/OpenGL. And QGIS would still have to be run within the GRASS
environment in order to maintain the command line access that many feel is
essential. Would the command-line modules run in the QT window or generate
their own independent x-windows? I'm not even sure that some modules that
produce displays (e.g., the wildfire spreading) would operate in the QGIS QT
display at all. These are all issues with GRASS, not QGIS. But they need to
be solved in an integrated way. Currently, we do have a reasonably
integrated UI in a functional sense whether people like green or not ;-).
Switching just a part of it to QGIS without revamping the interface more
generally would create something of a frankenstein's monster that would be
very forbidding for new users :-O. This is the opposite of what most people
are calling for.

So, even if 90% of the GRASS users and developers love the way QGIS is
organized, to implement it in the GRASS environment would take substantial
planning and reorganization of the UI to do it well. In other words, we
still need to systematically develop a next generation UI for GRASS. So,
back to my original question. For those of you who like QGIS a lot and use
it a lot, what features of the QGIS UI are something you'd like to see in
the GRASS GUI too? Also, are there any features that--as a GRASS/QGIS
user--you'd like to see implemented differently or that are missing in QGIS
and you'd like to see implemented? Let's create a vision of what a 21st
Century GIS ought to look like and see what we can come up with.

My personal view is that this is opportunity to make GRASS not just a free
version of the leading commercial GIS software, but a real leader in
providing complex spatial technologies that are accessible to a diverse,
international community of users. And importantly, help them learn how to go
beyond nice map making, and appropriately apply this technology to help
solve the many problems that involve spatial relationships.

Un saludo cordial
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: Stephan Holl <holl@gdf-hannover.de>
Organization: GDF Hannover bR
Date: Mon, 14 Nov 2005 15:59:48 +0100
To: <grass5@grass.itc.it>
Subject: Re: [GRASS5] Re: GRASS GUI and Qt

Hello Māris,

On Mon, 14 Nov 2005 16:36:25 +0200 Māris Nartišs <maris.gis@gmail.com>
wrote:

Hi,

IMHO keeping GRASS as GUI-less engine and having QGIS as GRASS GUI is
not a bad idea, but what will say qgis developers/users on this - they
app will become a frontend to grass. If we head this way, qgis
developers alsou shuld be invited to this discussion.

And if we talk about fragmentation of OS. I cannot understand why we
have a lots of OS GIS related apps that can do some things and in some
areas fail but we havent one killer app. Having 3 or more flavors of
GRASS GUI is same => at the end ESRI wins.

Following the thread a while now I would like to through in some
euro-cents of mine as well...

I really like the QGIS-GRASS-integration and in my eyes this should be
the focus of the GRASS-gui. It is _so_ easy adding new commands to the
GRASS toolbox and I really like to thank Radim for his work on this
topic!

So, please, let us focus the main work on pushing QGIS as a GRASS-UI
and not reinventing yet another GUI.

The more userinput for improving the current QGIS-GRASS-integration
the better it will become.

just my 0.02¢.

Stephan

--
GDF Hannover - Solutions for spatial data analysis and remote sensing
Hannover Office - Mengendamm 16d - D-30177 Hannover
Internet: www.gdf-hannover.de - Email: holl@gdf-hannover.de
Phone : ++49-(0)511.39088507 - Fax: ++49-(0)511.39088508

11

At 07:59, martedì 15 novembre 2005, Michael Barton has probably written:

The second item is something of a commentary of why QGIS cannot become THE
GRASS UI, but is ultimately related to the initial set of questions. Please
read on to the not so bitter end. This has nothing to do with the quality
of QGIS but is more of an issue of pragmatics. QGIS could become the
_basis_ for a GRASS interface, but could not become THE GRASS interface
without changing so that it is no longer QGIS.

I do not agree with this. Of course the design of the interface has to be
taken carefully, not to clutter it and confuse the user, but I do not see a
reason why qgis could not become THE grass interface.
Apart from strict functionality, it is the look&feel of qt that is much more
sleek and modern than tcltk, and that gives a much more pleasant user
experience.
pc
--
Paolo Cavallini
email+jabber: cavallini@faunalia.it
www.faunalia.it
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy Tel: (+39)348-3801953

12

On 11/15/05, Michael Barton <michael.barton@asu.edu> wrote:

I like the tabbed idea except that a nice
thing about having multiple monitors is so that you can compare them side
beside too. So maybe if the tabs were to tear off? This could be very nice.

I agree that the possibility to easily compare more maps is important
but is the need permanent during the session? My experience is
that I need to compare more maps only from time to time.
Multiple windows are also necessity for rectification (4 windows).
So the tabs which can become windows seems to be possible solution.

The question is what the monitors should share -
- list of layers ?
- current extent ?
Sometimes you need the same extent sometimes the same layers
and divverent extent (region).

Radim

13

On 11/15/05, Michael Barton <michael.barton@asu.edu> wrote:

QGIS could become the _basis_
for a GRASS interface, but could not become THE GRASS interface without
changing so that it is no longer QGIS.

You can consider QGIS the new monitor but everything other is done
in separated plugin where you can do whatever you want.
You forget also about interoperability, may users want to use
Postgis and WMS. New users can start with simple maps from
shapefiles and then (in the same enviroment) start to use GRASS.

If you create a sort of fork from QGIS, it will die
because of lack of developers. We could get so far with QGIS/GRASS
because I dont have to develop the whole QGIS but only the GRASS
part. In any case if you create a fork I will continue to work on QGIS.

We cannot put all those commands into Radim's very attractive GRASS
tool-box.

Why not? In fact I used the toolbox instead of menus because I believe
that to have 400 items in menus is wrong approach.
We can add for example search engine which cannot be done for menus.

And QGIS would still have to be run within the GRASS
environment in order to maintain the command line access that many feel is
essential. Would the command-line modules run in the QT window or generate
their own independent x-windows?

I am not sure what you mean, the shel was already integrated and
you don't have to run QGIS from GRASS.
http://mpa.itc.it/radim/qgis/shell1.png

Radim