[GRASS5] Proposal for GRASS UI roadmap

[Michael Barton]

Bob,

This is good timing indeed. It will be helpful to see what is possible in
different platforms. Because of your work with NVIZ--which I'm proposing to
become integrated into the display and control system--I'm very happy you
are thinking seriously about this and starting to test new options.

I still think it is a good idea to spec what the UI should be before going
too far down the road toward a particular interface platform.

One question I personally would have at some point is how easy is it to
develop in potential platforms? Because it is interpreted rather than
compiled, TclTk is easy for me to work with. However, it lacks much in the
way of development environments. I've briefly looked at QT (couldn't figure
out much, but didn't take much time) and haven't looked at GTK.

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: Bob Covill <bcovill at tekmap.ns.ca>
> Date: Sun, 06 Nov 2005 13:17:43 -0400
> To: Michael Barton <michael.barton at asu.edu>
> Cc: GRASS List <grass5 at grass.itc.it>
> Subject: Re: [GRASS5] Proposal for GRASS UI roadmap
> 
> Michael,
> 
> Good timing!
> 
> These past couple of weeks I have been digging into the existing display
> driver and now have a working GTK based display interface. I am now
> working on adding internal display options, etc. The UI is still quite
> early in development.
> 
> Once I have the basic bones of it working I will make it available for
> testing and improving.
> 
> --
> Bob
> 
> Michael Barton wrote:
>> Colleagues
>> 
>> A couple months back I suggested a discussion on the specifications for
>> the next generation user interface for GRASS. Perhaps because it was
>> summer--or perhaps because everyone is just so happy with what I¹ve done
>> so far ;-)--there were few takers. However the comments were useful.
>> I¹ve included all of them in the attached text file as I promised to do.
>> 
>> Now that we are thinking about GRASS 6.2 and 7, we need to actively
>> consider the way in which GRASS presents itself to users. GRASS is a
>> great program and current development is making it an outstanding piece
>> of software for managing, visualizing, analyzing, and modeling very
>> diverse spatial data. But this tremendous capability will go
>> unrecognized if potential users become frustrated in trying to make it
>> work. Because of its power and versatility, and because GIS is a complex
>> subject, it is a challenge to make GRASS accessible to users‹even ones
>> with considerable experience with computer graphics, CAD, and other
>> GIS¹s. This same challenge is faced by other high-end GIS systems. To
>> some extent, we are still trying to work out appropriate display and
>> control metaphors for GIS, and a large part of the existing UI¹s are
>> still a lot like word processors and drawing programs, although GIS is
>> neither. An automobile may have a great engine and suspension system,
>> but if it lacks a steering wheel or comprehensible gauges its
>> performance will be underutilized. So the UI is important.
>> 
>> In order to make discussion easier, I want to float a proposal for the
>> next generation UI for GRASS. This will give people a concrete target to
>> take shots at, say they like, or offer modifications or additions. This
>> is perhaps a more effective way to do this than simply asking for input,
>> and I think I¹ve got a thick enough skin to offer my proposal for
>> critiquing‹of course it is pretty close to perfect so I shouldn¹t have
>> to worry much ;-) In any case, it is a start on which we can begin to build.
>> 
>> I¹ve tried to build on what works well now, to think out of the box a
>> bit to envision how a GIS can be easier to use, and to be realistic
>> about what can be accomplished in an open source project like this one.
>> GRASS has some excellent features that set it apart from other GIS
>> systems. Ones that always impresses people I show it to are the
>> visualization capabilities. It is extraordinarily flexible and fast at
>> visualizing complex spatial data. I think we should build on that, along
>> with GRASS¹s excellent  analytical abilities for raster data as unique
>> and distinguishing features of the GRASS system. (I¹d like to suggest
>> that we think of beefing up the already strong modeling capabilities of
>> GRASS by adding predictive and agent modeling, but that¹s another issue).
>> 
>> Some of the items in the proposal could be implemented pretty soon,
>> using the TclTk tools we use now. Other parts will require more
>> sophisticated use of TclTk or a different GUI development system. Yet
>> other parts will require new C-programming. Because a next generation
>> GUI will require skills beyond my own and team effort, your input is
>> essential.
>> 
>> One thing to note is that I am not recommending a platform for
>> implementing this at this point. I¹m pretty sure it could be implemented
>> in TclTk if we get more sophisticated in using that platform. However,
>> it might be better to implement it in another platform like QT or GTK.
>> As I said last summer, however, I think it is better to decide what kind
>> of UI we want and THEN decide which available platform is the best way
>> to implement it.
>> 
>> I guess that is enough preamble. The proposed roadmap is below. Please
>> let me know what you think over the next few weeks. At some point, it
>> might be good to send it to the larger GRASS user list for input from
>> the people who will have to make it work.
>> 
>> Thanks to all of you for your support over the past two years.
>> 
>> 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
>> 
>> 
>> ==================================
>> 
>> 
>> PROPOSAL FOR A USER INTERFACE ROADMAP FOR GRASS 6.X AND 7
>> 
>> DISPLAYS
>> 
>> ***Display windows:
>> Keep ability to have multiple display windows. Display should have the
>> potential to display both 2D and 3D graphics. Display windows should get
>> focus by clicking with mouse. It should be necessary to run a module
>> like d.mon select simply shift the focus to a different display window.
>> 
>> ***2D and 3D visualization:
>> 2D and nD visualization should be seamlessly integrated. The "normal"
>> view would be 2D like current x displays and standard GIS. Clicking a 3D
>> (nviz) button would open a floating window with 3D controls (like in
>> nviz now) but not a new display window. This would allow user to tilt,
>> rotate, change z, visually separate layers, etc. It would work with the
>> same layers shown in 2D mode, but would simply display them in 2.5D or
>> 3D. Nviz would not be a separate module, opening a separate display
>> window and separate layer control panel; it would simply display any
>> active layers in 3D "mode".
>> 
>> DISPLAY CONTROL GUI AKA GIS MANAGER
>> 
>> We should keep single display control (like current GIS Manager).
>> distinct from the  display window(s). This allows for multiple display
>> windows to be controlled from single interface. Display "commands"
>> should be integrated into display control interface; there would be no
>> separate d.* command modules. That is, the display control system should
>> be able to directly draw graphics to a display window, without going
>> through intermediate, stand alone programs. We need to rethink how these
>> would best be implemented (e.g., should we combine thematic vector and
>> chart display functions?) Display functions should still be scriptable
>> as in nviz and d.m, just not independent "commands". It should be
>> possible to run a display script from the command line to automate mapping.
>> 
>> ***Buttons:
>> There should be 1 row of buttons for display controls (zoom, pan, erase,
>> 3D, query, layer management, open display window, save, print, etc). We
>> should change current display in region buttons to simply region setting
>> buttons (default, select saved region). We will no longer need a display
>> button (see layers specs below)
>> 
>> There should be a 2nd row of buttons for adding layers. This could be
>> space-optimized by making pull-down groups (e.g., vector group would
>> include vector, 3D vector, chart, thematic, etc) with last-used
>> layer-type showing up in the button bar.
>> 
>> ***Layers:
>> Any function than can be thought of as a layer should be implemented as
>> one. It is a nice and pretty intuitive metaphor. It is easy to work with
>> conceptually and comparable to graphic and CAD programs. Layers should
>> include 3D vectors and volumes (see below) along with the kinds of
>> layers now in the GIS manager.
>> 
>> We should keep layer-tree metaphor. The hierarchical arrangement is
>> intuitive and easy to work with. Nested groups are an especially nice
>> touch. We may want to switch from arranging the layer in the order they
>> will be displayed (first at the top, last at the bottom), to a stacked
>> metaphor (last displayed at the "top" of the stack). This is more in
>> line with other GIS programs and most graphics programs, and would make
>> GRASS less confusing to a new user.
>> 
>> Adding a layer to the layer tree should automatically display it when
>> the 'active' box is checked. There should be no need for display button.
>> Checking or unchecking the 'active' box should automatically display  or
>> undisplay the layer. Should layers be added in an non-activated state by
>> default so that the user can choose to display the newly added layer
>> when ready?
>> 
>> There should be an independent layer tree for each display window open.
>> Selecting display window with the mouse displays the associated layer
>> tree. This permits multiple displays of different information controlled
>> from same interface. User should be able to copy existing layer tree to
>> a new or open display window.
>> 
>> ***Option panes:
>> Option panes should open in a separate window when an entry in the layer
>> tree is double clicked. This will optimize space in the display control
>> GUI. There should be "apply" and "save and close" buttons so that an
>> option pane can be kept open if desired.
>> 
>> We should add a "layer name" field to the option pane rather than adding
>> a layer name by typing it into the layer tree. This makes it more
>> "permanent" so that it is not erased when a new map is chosen to be
>> displayed in that layer. If it is empty, the name of the map will go in
>> by default; if something has been typed in it, it will stay and not be
>> overwritten (make this a question when opening a file?)
>> 
>> ***Pull-down menus:
>> Keep menus as we have now for file, configuration, GIS function (raster,
>> vector, 3D), database, extensions (I'm assuming that the GRASS Extension
>> Manager will be default soon). Do we need a separate menu for help or
>> can it go into configure or something like that? Menus should call
>> independent modules that can also be run from the command line. GRASS
>> needs to remain scriptable for complex tasks and functions should be
>> useable from command line for "power users".
>> 
>> RELATED UI ISSUES
>> 
>> ***Attribute data management:
>> Now that GRASS has vectors with linked attribute data, there needs to be
>> a reasonably decent UI for attribute data management and queries.
>> Perhaps this could be developed along with the switch to a default
>> attribute dbms based on SQLite.
>> 
>> ***Printing:
>> There should be integrated WYSIWYG printing to multiple devices from the
>> GUI, including PDF files. ps.map functions should be integrated into GUI
>> and be accessible without creating complex text file scripts.
>> 
>> ***Display output:
>> Users should be able to save WYSIWYG display output to multiple graphic
>> formats without scripting through a png driver or using gdal_translate.
>> Formats supported should at least include tif, png, pnm, gif, jpg, svg,
>> and xcf.
>> 
>> ***Exiting:
>> It should be possible to exit GRASS from the GUI rather than having to
>> separately type "exit" on the command line.
>> 
>> 
>> 
>>