[GRASS5] More GRASS GUI thoughts...

[Christian Wygoda]

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