[GRASS5] New gui.tcl generic user interface

[Cedric Shock]

Hi,

>
> 1. Maintaining a consistent look/function across different parts of the
> GRASS UI. Cedric, your use of the same icons used in the GIS Manager makes
> it much easier for users to operate diverse GRASS modules and displays. It
> will also make it easier for people to use the GIS Manager. Can we move
> toward the same kind of consistency in NVIZ? There are some other places
> for consistency.
>
> I changed TclTk entry widgets to white to signal that the user needs to
> enter something there. I did the same for the output text widgets. You
> might want to do the same.
>
> I'd also changed the title of the option pane to blue--again to signal that
> it is a title. Yours look very nice in black however. What do you all
> think? Should we change the module titles to a different color (blue or
> something other than black) or my option pane titles back to black?

We need to agree on names of fonts and a global variable and structure for 
colors as well as on a file to source to get them. I suggest a global 
gui_style variable. It would be indexed by class and attribute, like this:

set gui_style(button,background) red
set gui_style(button,foreground) yellow
set gui_style(button,font) funfont
...

We would have two commands:
style_set_class $path $class
Which would set the class of a widget to that specific class (it defaults to 
its actual widget class)

And
style_apply $path
Which would recursively apply the style to that widget and all of its 
children. It would also apply a default style gui_style(default,$attribute) 
if applicable, and also apply styles of class inheritence (if this is 
defined).
style_apply would also configure DynamicHelp based on the ballon-help style.

We could then do fun stuff like:
button .ok -text "Yes"
style_set_class .ok ok-button

with a style like this:
set gui_style(ok-button,image) [icon buttons ok]
set gui_style(ok-button,text) $LANG::Ok (Makes iternationalization easier)

Then we'd need a little ui for setting fonts and changing all of these.

This should be really simple and very impressive.

Here are the classes I've already thought of:
title - title text for a window or pane
balloon-help - handled by a special rule (probably the only special rule)

Any others you want? They can't be the names of tk classes (like label). 

>
> Benjamin Ducke suggested adding a notebook widget to complex option panes
> to help organize them. I don't really need a separate tab for output from
> the GIS Manager, but tabs for organization might help. This probably only
> really applies to vector panels (including chart and thematic). Any
> thoughts? Tabs might be very helpful in NVIZ.

I don't understand why the command log is in the main window of gis.m. I have 
never been interested in what it says. I don't know what the buttons across 
the bottom do at all, except for clear and open output window. I'm obviously 
completely ignorant of what that is all for, but I think that log, and the 
progress bar (display progress is shown in the other window), and the buttons 
should go with the output somehow, giving more room for the main event. 

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

Icons are in $GISBASE/etc/gui/icons to avoid confusion with symbols. Easily 
work with QT, GTK. You can use [icon $class $member] from sourced gui.tcl to 
load icons from there.

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

No matter what I did I could not get <MouseWheel> <Button-4> and <Button-5> to 
bind to and actually throw events from anything but All. This is a memory 
leak and a code leak over the course of frames being created and destroyed 
(the binding never goes away). I just realized there is a better way to do 
this; I can manage the list of bindings myself and we'd need only one set of 
All bindings. I tried this approach before to try to get events but events 
just slide right off, however if I dispatch with commands from a global it'll 
work. I'll make something like bind_scroll $path for you that will do it all.

>
> 4) Continuing to debug the GIS Manager so that it can become the default
> GUI soon. There are several small tweaks I'd like to make.

I've got two tiny bugfixes.

> But the main 
> issue right now are strange results from compositing with g.pnmcomp. I have
> no idea what's causing these. Cedric, since you appear to know both TclTk
> and C pretty well, I'd like to ask if you can help us sort this out?

Is g.pnmcomp written in both c and tcl? Can you put together a set of the 
files that get composited and the commands and point out what's wrong with 
the output?

--Cedric Shock