[GRASS5] Re: GRASS GUI and Qt

[Radim Blazek]

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 at 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. ;-)
>
> 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
>
> _______________________________________________
> grass5 mailing list
> grass5 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
>