[GRASS5] Re: GRASS GUI and Qt

[Radim Blazek]

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
>