[GRASS5] Re: GRASS GUI and Qt

[Michael Barton]

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 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