<HTML>
<HEAD>
<TITLE>Next generation GRASS UI discussion summary</TITLE>
</HEAD>
<BODY>
<FONT FACE="Verdana, Helvetica, Arial"><SPAN DEFANGED_STYLE='font-size:12.0px'>I put together the many posts from the recent discussion about the direction GRASS should go with respect to its user interface. I’ve posted the details on my website at <a href="http://www.public.asu.edu/~cmbarton/files/grass_ui"><http://www.public.asu.edu/~cmbarton/files/grass_ui></a>. I tried to summarize the feature discussion (separate from the platform discussion) in the file named distillation. Here is an ‘executive summary’ of that distillation. Happy holidays.<BR>
<BR>
Michael<BR>
<BR>
<B>Windows and Monitors: </B>Multiple monitors are preferred. User should be able to hide/dock unused monitors. Layer settings should be linked with monitor (i.e., each monitor can have its own layers and settings). One idea is to have pages and frames. Frames would contain maps or other information and could be arranged on pages. This like layouts in other GIS's.<BR>
<BR>
<B>3D:</B> Integrated, seamless 3D has very strong support. OpenGL seems to be the most likely platform. VTK libraries mentioned. OpenGL is not without issues, however. It still may have problems on some platforms. But some question whether this is this really still an issue now? There is some sentiment for making OpenGL optional if possible (But can GRASS be compiled without it today?)<BR>
<BR>
<B>Controls/Tools:</B> Basic, interactive display functions (zooming, panning, mouse query, etc.) should be integrated into GUI. Check Thuban for example. Controls should be efficient (e.g., single button for zoom in and out like in graphics programs). Drop-down tools might be necessary for some functions. But output modules like d.rast should still have CLI equivalents.<BR>
<BR>
<B>Layers:</B> Keep layer tree. New layer should go above selected layer. Should be able to cut/copy/paste multiple layers and groups. No comments on auto-redraw. Make it an option?<BR>
<BR>
<B>Menus:</B> Separate help menu. Menus should not display too much at one time. May want to rethink organization.<BR>
<BR>
<B>Functionality:</B> Better thematic cartography. Better digitizing and georeferencing. Many want GUI for attribute table management. SQLite OK if it helps with this. WYSIWYG output wanted, but may not need as many formats as suggested. Customization desirable for GUI. <BR>
<BR>
<B>CLI: </B>We must keep the CLI. The CLI should integrate with GUI so that it's easy to go from one to the other (e.g., GUI produces commands in a CLI window that can be edited and run from the same window). The GUI should help people learn the CLI if they want to do so. Scripting remains essential.<BR>
<BR>
__________________________________________<BR>
Michael Barton, Professor of Anthropology<BR>
School of Human Evolution and Social Change<BR>
Arizona State University<BR>
Tempe, AZ 85287-2402<BR>
<BR>
phone: 480-965-6213<BR>
fax: 480-965-7671<BR>
www: <a href="http://www.public.asu.edu/~cmbarton">http://www.public.asu.edu/~cmbarton</a> <BR>
<BR>
</SPAN></FONT>
</BODY>
</HTML>