[GRASS5] Proposal for GRASS UI roadmap

[Bob Covill]

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