[GRASS-dev] Re: gis.m: font selection in module panels

[Paul Kelly]

Hello all
I returned to this problem because I noticed there was still some 
unpredictable behaviour on Windows and we never really solved it.

On Sun, 20 May 2007, Michael Barton wrote:

> It seems like the issue is that this method to check to see if a variable
> has been set won't work under windows.
>
> if {[info exists VAR]} { do something }

Yes indeed. After a bit more web searching I found some discussion of a 
specific problem with using "info exists" on the env array on Windows. 
Seemingly related to the fact that Windows handles the unsetting of an 
environment variable by setting it to an empty string, and the way Tcl 
maps the env array directly to the environment on the system it is running 
on gets confused by this.

> Maybe if I wrap it in a catch statement...? Anyone have a suggestion about
> this.

Yes, exactly! That was the workaround that was suggested in the 
discussion thread I found:
Change
[info exists env(GRASS_FONT)]
to
![catch {set env(GRASS_FONT)}]

This works because set env(GRASS_FONT) tries to read the variable - if it 
doesn't exist, throws an exception, which is caught by the catch command. 
And if there is no catch (! negation operator used), then it means the 
variable does actually exist.

> If the diagnosis is correct, it is a fairly major projblem. This same method
> of testing if a variable exists is sprinkled throughout the GUI code, so we
> need to find an alternative. I don't know what it would be at the moment.

It seems the problem is specifically related to using info exists on the 
env array on Windows. So not too widespread. I have changed all the 
occurences in gis.m to the workaround and committed it to CVS.

I also changed the text of the font selection box from "Select default 
font for GRASS displays" to "Select GRASS display font", as the former 
text was quite confusing seeing as the font select box is also used in the 
widgets for d.text, d.histogram etc. to select a temporary fault to 
override the default. I also found a related bug there, which I now know 
how it's caused but don't know enough Tcl/Tk to fix it:

When clicking the font button in d.histogram for example, it will default 
to having the default font (loaded from the GRASS_FONT environment 
variable) selected, not the last font that was selected for d.histogram - 
a little confusing there, but not a big deal. However the main problem is 
that if you just click OK here, you would expect the font that was 
displayed as selected in the select box to be set as the font for 
d.histogram to use. But it is not, unless you first go and click on it 
(and nothing *appears* to change, because it was already selected). Very 
confusing. The reason seems to be that the command that sets the font to 
the one selected is bound to the <<ListboxSelect>> event, which is only 
triggered when the font selection is *changed*. Clicking on it again 
triggers this event, but it's not reasonable to expect users to do that 
when it already is selected. I think it would be more logical (and solve 
this problem) if the command that sets the font from the select box was 
instead bound to the OK button, but I don't know enough to see how to 
change this...

Paul