[GRASS5] Proposal for GRASS UI roadmap

Martin Wegmann wegmann at biozentrum.uni-wuerzburg.de
Sun Nov 6 09:36:32 EST 2005


hello Michael, 

your ideas are very good & needed. By chance I found this page 
http://crischan.net/qgrass with a Q GRASS approach, however it is in its very 
first steps but it sounds pretty promising. 
I asked Chrischan to present the very first version in GRASS-News vol.4 and 
perhaps you both could benefit from each others skills/knowledge/experience.

regards, Martin

On Sunday 06 November 2005 05:59, 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.

-- 
Martin Wegmann

DLR - German Aerospace Center
German Remote Sensing Data Center
@
Dept.of Geography
Remote Sensing and Biodiversity Unit
&&
Dept. of Animal Ecology and Tropical Biology
University of Wuerzburg
Am Hubland
97074 Würzburg

phone: +49-(0)931 - 888 4797
mobile: +49-(0)175 2091725
fax:   +49-(0)931 - 888 4961
http://www.biota-africa.org
http://www.biogis.de




More information about the grass-dev mailing list