[GRASS5] Re: GRASS GUI and Qt

Mon Nov 14 05:47:36 EST 2005

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

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 at wygoda.net>
> > > Date: Mon, 07 Nov 2005 18:52:00 +0100
> > > To: <grass5 at 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 at grass.itc.it
> > http://grass.itc.it/mailman/listinfo/grass5
>
> _______________________________________________
> grass5 mailing list
> grass5 at 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