[GRASSGUI] Re: More GRASS GUI thoughts...

[Michael Barton]

Chris, Bob, et al.

These ideas are exciting. Here are a couple of brief responses.

Rendering:

Having an "auto mode" switch for rendering is a great idea.

Display organization:

The think I personally don't like about the ArcGIS (and QGIS) interface is
that each display must also carry around a full set of buttons, menus, and
layer tree. This takes up valuable display space. Actually Idrisi has a
better implementation of the MDI. I like the tabbed idea except that a nice
thing about having multiple monitors is so that you can compare them side
beside too. So maybe if the tabs were to tear off? This could be very nice.

I'd been thinking more along the lines of your 3rd model, but with a single
toolbox that changes state depending on which monitor has the focus. Perhaps
this is actually operationalized with multiple toolboxes in the same spot
that are hidden or displayed depending on which monitor has the focus.

But maybe everyone else likes the idea of each monitor having its own set of
tools, layers, etc. attached--like in ArcGIS--and I'm the only one that
finds that clunky.

I also like your description of the GIS Manager toolbox. This is something
along the lines of how I was envisioning it to make it compact, but rich.

3D:

I understand Glynn's concern about OpenGL issues on some systems. I don't
know how much of a problem that really is now with current OS's. But I think
that integrating 2D and 3D displays in a seamless way would be a great goal
to work towards. This is something that no other GIS package even comes
close to. For GRASS, it is  only the speed and efficiency of NVIZ that makes
this potentially doable. Ideally, I suppose, it would be best to make it so
that on systems without OpenGL or OpenGL problems, the 3D mode is simply
non-functional but the rest of the system works normally.

Let's let the discussion simmer for awhile. I'm going to echo your
suggestion to post to grassgui. Then in a couple weeks--maybe over Christmas
break--we can start looking through the comments and come up with specs,
think honestly and neutrally about platforms, and make a proposal to the
developer's list. How's that sound.

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, 15 Apr 2002 06:49:38 +0200
> To: 'Michael Barton' <michael.barton at asu.edu>, <grass5 at grass.itc.it>
> Cc: 'Bob Covill' <bcovill at accesswave.ca>, GrassGUI <grassgui at grass.itc.it>
> Subject: More  GRASS GUI thoughts...
> 
> 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
>