[GRASS5] New gui.tcl generic user interface

[Michael Barton]

Cedric,

Some responses to your questions below.

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



> From: Cedric Shock <cedricgrass at shockfamily.net>
> Date: Fri, 17 Mar 2006 08:33:54 -0800
> To: <grass5 at grass.itc.it>
> Subject: Re: [GRASS5] New gui.tcl generic user interface
> 
> 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).

This would be quite welcome. I just haven't had time to do it with the rest
of GIS Manager rewrite.

There are some style variables that could be set for the GIS Manager.
Background color is already global variable $bgcolor. There is a font
variable for the toplevel mainframe. I don't know if it affects the menus or
not. However, we could (and should) easily add this. The option pane title
could use the same variable that you do, along with the option pane text,
button appearance, and balloon help. We should probably use the same color
progress bars. I use the default blue, but I think the green in the modules
is kind of dayglow. This could also be a global variable (whether or not it
is user setable). 

I don't think we need to make everything user setable (e.g., button style),
as this could make for a long and complicated interface. However, encoding
as much of the appearance as possible in global style variables to be used
across the interface is a very good idea.

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

This is not just a command log anymore. It is a console for running
commands. If you place your cursor on a command and press "run", it sends
the command to the GRASS command parser. The idea is be able to run GRASS
without x11. You can also save a selected command history to a text file to
track what you've done or put it into a script. Because it is a TclTk text
widget, the command console is fully editable--considerably easier than in
an xterminal.

Currently, there are 2 limitations to the command console as a replacement
for the xterminal. One is that running display commands is a little
problematic, though that should be less of a problem as Glynn changes them
to output PPM files. The second is commands that require interactive input
in an xterminal. It seems that there should be some way around this, but I
haven't found it yet.

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

OK. Once I'm back up and running with my computers (by next week I hope),
I'll switch all the GIS Manager icon calls to the $GISBASE/etc/gui/icons
folder. I'd been thinking of something like this to clean up the gm folder.

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

Thanks

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

OK. What are they? I don't want to accidentally overwrite them.

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

G.pnmcomp is in C.

Here is what is happening on my Mac and at least some Linux systems.

1. I composite >2 layers to create a final map in g.pnmcomp. The 1st time I
do it, it works fine.

2. I change one of the layers. The next time I composite, I only see the
same final map created the FIRST time I ran g.pnmcomp.

3. I run g.pnmcomp with only 2 layers, add back in the additional layers,
and run g.pnmcomp again. I get the correct result.

I've done this via the GIS Manager AND from the command line. I've looked at
the PPM input files AND the PPM output file and confirm that this is really
happening. Especially baffling is that there is no apparent place that
g.pnmcomp is getting the wrong information to composite. That is, the old
input files are overwritten with the new data. So how can g.pnmcomp create
an output composited map that matches input files that no longer exist?

This issue is making it very difficult to debug any other compositing
issues. I want to check to see if the previous version of g.pnmcomp (before
transparency support was added on 21 February) gives the same behavior, but
haven't had a chance to do it yet.

The GUI is a LOT of lines of code. It's really a pleasure to have some more
help with it.

Michael