[GRASS5] New gui.tcl generic user interface

[Michael Barton]

> From: Glynn Clements <glynn at gclements.plus.com>
> Date: Fri, 17 Mar 2006 10:14:19 +0000
> To: Michael Barton <michael.barton at asu.edu>
> Cc: Cedric Shock <cedricgrass at shockfamily.net>, <grass5 at grass.itc.it>, Massimo
> Cuomo <m.cuomo at acsys.it>, Trevor Wiens <twiens at interbaun.com>, Christian
> Wygoda <crischan at wygoda.net>, Benjamin Ducke <benjamin.ducke at ufg.uni-kiel.de>
> Subject: Re: [GRASS5] New gui.tcl generic user interface
> 
> 
> Michael Barton wrote:
> 
>> 2. Using the same resources. Icons are the most obvious one at the moment.
>> We should put them all in the same place and all GUI components using them
>> could then get at them. I saw mention of $GISBASE/etc/icons Cedric. This
>> seems OK with me. Crishan and Glynn, if we shifted to QT, GTK, or another
>> GUI platform, would these also use GIF icons? Could they still be kept in
>> $GISBASE/etc/icons?
> 
> GTK and Qt both have image-loading mechanisms which will load any of
> the common image formats without the application needing to worry
> about the details.

OK. I'll shift all GIS Manager icon calls to this new standard directory.
> 
>> 3. Consistent functionality. For example, I don't think that module output
>> should go to the output window at this  time. The reason is that some people
>> would rather work without the GIS Manager. If all output goes to the output
>> pane, then the GIS Manager would always need to be launched.
> 
> I suspect that this is a misunderstanding. The standalone UI would
> send output to a text widget which was part of the UI dialog, as
> happens now. A monolithic UI application such as d.m or gis.m would
> omit the text widget from the per-command dialogs and send all output
> to a single console window.

Right. We're kind of between either right now.

> 
>> Also, if you can tell me how to bind the mouse wheel to widget scrollbars, I
>> will implement it in the GIS Manager option panes too.
> 
> Search for handle_scroll in gui.tcl. Scrollable windows usually have a
> "yview" command which can be used to change the scroll offset.

Cedric noted that this is more complicated than it ought to be, but will
share the protocol he worked out.

> 
>> 4. Finally, we all might want to look at the UI roadmap on the GRASS WIKI
>> again. This is not set in stone, but should serve as a guide (an evolving
>> one) to moving to the next generation UI in a coordinated fashion. Along
>> these lines, Trevor proposed some nice ideas on how to implement some of the
>> roadmap ideas. Some echo some of the design ideas that Crishan proposed a
>> couple months back. (Could you put this on the WIKI in the UI section?).
>> This would involve adding a tabbed notebook to the GIS Manager so that it
>> could serve increasingly as a tool box for launching GRASS modules--rather
>> than only having them launched from (sometimes deeply hierarchical) menus.
>> The new generic module GUI's fit very nicely into this scheme.
>> 
>> To close, here are some other ideas that I've been thinking about for
>> continued updates to the UI.
>> 
>> 1) using r.profile and TclTk charts to create a new terrain profile utility
>> that would replace d.profile, produce postscript text and graphics, and not
>> need x11.
> 
> That would be nice, but v.digit is probably the most urgent candidate
> for replacement, followed by i.points.

I agree that these are more important. But they take rewriting the relevant
C code, so someone other than me will need to work on this.

> 
> More generally, in order to be able to show existing vector maps in a
> Tk canvas, we need a way to export vectors to a usable text format.
> 
> v.out.ascii has the (major) drawback that areas are output as disjoint
> segments which the application then has to piece together to form
> closed polygons. AFAICT, currently the only tool which provides
> polygons is v.out.pov, but that loses all of the structural
> information.

If solved, this would produce the kind of high quality vector output that
many people wish for.

I'd add the integration of NVIZ and 2D displays as another important goal
for the raster side.

> 
> -- 
> Glynn Clements <glynn at gclements.plus.com>


__________________________________________
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