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

[Michael Barton]

Thanks for this really insightful diagnosis of a difficult problem. I'm just
returned and am going to be delving back into the TclTk GUI for a few more
fixes soon. I'll try to see what can be done about the font selection
bindings.

Michael


On 7/27/07 7:31 AM, "Paul Kelly" <paul-grass at stjohnspoint.co.uk> wrote:

> 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

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton