[GRASS5] New gui.tcl generic user interface

[Glynn Clements]

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.

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

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

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

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.

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