[GRASS-dev] Problem with font selection in gis.m on Windows

Paul_Kelly · May 4, 2007, 4:06pm

The recent talk of fonts on this list brought me to try out some stuff on Windows. I discovered there's a font selector control in gis.m (Config Menu-->Set default display font) but if I click the button to try and change it to anything other than Romans I get the following error:

couldn't execute "uname": no such file or directory
     while executing
"exec uname -s"
     (procedure "Gm::SelectFont" line 7)
     invoked from within
"Gm::SelectFont"
     ("uplevel" body line 1)
     invoked from within
"uplevel \#0 $cmd"
     (procedure "Button::_release" line 18)
     invoked from within
"Button::_release .dispfont.fontopt2.b"
     (command bound to event)

Obviously trying to use the "uname" command (not available on native Windows) is the bug, but looking closer at the code (line 537 onwards in gui/tcltk/gis.m/gm.tcl) it seems the relevant part is trying to put together directories to search for Freetype fonts in? Which
(a) shouldn't even be needed here as I have the stroke font radio button in the dialog selected and don't even have GRASS compiled with Freetype support and
(b) might possibly be being made redundant by Glynn's new script to populate $GISBASE/etc/freetypecap?

Not sure what's the best way to fix this, taking into account those points.

Paul

cmbarton · May 5, 2007, 5:10pm

I lifted this from Init.sh, where it checks for things like Mingw and
Cygwin, so I thought it would work with windows. If it doesn't, I guess it's
pointless to have it in Init.sh too.

As the current font selection is done, I need to know if a Mac, Windows, or
other system is running to know where to look for fonts. If uname doesn't
work on Windows, I don't know how to find this out.

If there is no other solution, I'll try to implement an alternate kind of
dialog, using a listbox and the new and improved freetypecap file, like I've
done for the wxPython GUI.

Michael

On 5/4/07 9:06 AM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

The recent talk of fonts on this list brought me to try out some stuff on
Windows. I discovered there's a font selector control in gis.m (Config
Menu-->Set default display font) but if I click the button to try and
change it to anything other than Romans I get the following error:

couldn't execute "uname": no such file or directory
couldn't execute "uname": no such file or directory
     while executing
"exec uname -s"
     (procedure "Gm::SelectFont" line 7)
     invoked from within
"Gm::SelectFont"
     ("uplevel" body line 1)
     invoked from within
"uplevel \#0 $cmd"
     (procedure "Button::_release" line 18)
     invoked from within
"Button::_release .dispfont.fontopt2.b"
     (command bound to event)

Obviously trying to use the "uname" command (not available on native
Windows) is the bug, but looking closer at the code (line 537 onwards in
gui/tcltk/gis.m/gm.tcl) it seems the relevant part is trying to put
together directories to search for Freetype fonts in? Which
(a) shouldn't even be needed here as I have the stroke font radio button
in the dialog selected and don't even have GRASS compiled with Freetype
support and
(b) might possibly be being made redundant by Glynn's new script to
populate $GISBASE/etc/freetypecap?

Not sure what's the best way to fix this, taking into account those
points.

Paul

__________________________________________
Michael Barton, Professor of Anthropology
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

Paul_Kelly · May 6, 2007, 4:05am

uname will generally be available if Init.sh works, but Init.sh only runs in Msys on Windows - true native Windows GRASS doesn't require Msys for running (only compiling) and won't have Unix commands like uname available at run-time. We have an alternative Windows batch file, init.bat, that can be used to start native Windows GRASS and avoids the need to have a shell interpreter and run Init.sh.

Usually I did platform checking in Tcl by looking for environment variables that were platform-specific, e.g. something like:
if {[info exists env(OS)] && $env(OS) == "Windows_NT"}
but I see in the new d.rast.edit Glynn has used some kind of Tcl variable which looks like an even neater way of doing it:
if {$tcl_platform(platform) == "windows"}

But I agree it's best to wait to see how the font support settles down before we decide how best to fix this.

On Sat, 5 May 2007, Michael Barton wrote:

I lifted this from Init.sh, where it checks for things like Mingw and
Cygwin, so I thought it would work with windows. If it doesn't, I guess it's
pointless to have it in Init.sh too.

As the current font selection is done, I need to know if a Mac, Windows, or
other system is running to know where to look for fonts. If uname doesn't
work on Windows, I don't know how to find this out.

If there is no other solution, I'll try to implement an alternate kind of
dialog, using a listbox and the new and improved freetypecap file, like I've
done for the wxPython GUI.

Michael

On 5/4/07 9:06 AM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

The recent talk of fonts on this list brought me to try out some stuff on
Windows. I discovered there's a font selector control in gis.m (Config
Menu-->Set default display font) but if I click the button to try and
change it to anything other than Romans I get the following error:

couldn't execute "uname": no such file or directory
     while executing
"exec uname -s"
     (procedure "Gm::SelectFont" line 7)
     invoked from within
"Gm::SelectFont"
     ("uplevel" body line 1)
     invoked from within
"uplevel \#0 $cmd"
     (procedure "Button::_release" line 18)
     invoked from within
"Button::_release .dispfont.fontopt2.b"
     (command bound to event)

Obviously trying to use the "uname" command (not available on native
Windows) is the bug, but looking closer at the code (line 537 onwards in
gui/tcltk/gis.m/gm.tcl) it seems the relevant part is trying to put
together directories to search for Freetype fonts in? Which
(a) shouldn't even be needed here as I have the stroke font radio button
in the dialog selected and don't even have GRASS compiled with Freetype
support and
(b) might possibly be being made redundant by Glynn's new script to
populate $GISBASE/etc/freetypecap?

Not sure what's the best way to fix this, taking into account those
points.

Paul

__________________________________________
Michael Barton, Professor of Anthropology
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

cmbarton · May 6, 2007, 7:17am

Thanks for the useful tips.

Michael

On 5/5/07 9:05 PM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

uname will generally be available if Init.sh works, but Init.sh only
runs in Msys on Windows - true native Windows GRASS doesn't require Msys
for running (only compiling) and won't have Unix commands like uname
available at run-time. We have an alternative Windows batch file,
init.bat, that can be used to start native Windows GRASS and avoids the
need to have a shell interpreter and run Init.sh.

Usually I did platform checking in Tcl by looking for environment
variables that were platform-specific, e.g. something like:
if {[info exists env(OS)] && $env(OS) == "Windows_NT"}
but I see in the new d.rast.edit Glynn has used some kind of Tcl variable
which looks like an even neater way of doing it:
if {$tcl_platform(platform) == "windows"}

But I agree it's best to wait to see how the font support settles down
before we decide how best to fix this.

On Sat, 5 May 2007, Michael Barton wrote:

I lifted this from Init.sh, where it checks for things like Mingw and
Cygwin, so I thought it would work with windows. If it doesn't, I guess it's
pointless to have it in Init.sh too.

As the current font selection is done, I need to know if a Mac, Windows, or
other system is running to know where to look for fonts. If uname doesn't
work on Windows, I don't know how to find this out.

If there is no other solution, I'll try to implement an alternate kind of
dialog, using a listbox and the new and improved freetypecap file, like I've
done for the wxPython GUI.

Michael

On 5/4/07 9:06 AM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

The recent talk of fonts on this list brought me to try out some stuff on
Windows. I discovered there's a font selector control in gis.m (Config
Menu-->Set default display font) but if I click the button to try and
change it to anything other than Romans I get the following error:

couldn't execute "uname": no such file or directory
couldn't execute "uname": no such file or directory
     while executing
"exec uname -s"
     (procedure "Gm::SelectFont" line 7)
     invoked from within
"Gm::SelectFont"
     ("uplevel" body line 1)
     invoked from within
"uplevel \#0 $cmd"
     (procedure "Button::_release" line 18)
     invoked from within
"Button::_release .dispfont.fontopt2.b"
     (command bound to event)

Obviously trying to use the "uname" command (not available on native
Windows) is the bug, but looking closer at the code (line 537 onwards in
gui/tcltk/gis.m/gm.tcl) it seems the relevant part is trying to put
together directories to search for Freetype fonts in? Which
(a) shouldn't even be needed here as I have the stroke font radio button
in the dialog selected and don't even have GRASS compiled with Freetype
support and
(b) might possibly be being made redundant by Glynn's new script to
populate $GISBASE/etc/freetypecap?

Not sure what's the best way to fix this, taking into account those
points.

Paul

__________________________________________
Michael Barton, Professor of Anthropology
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

__________________________________________
Michael Barton, Professor of Anthropology
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

cmbarton · May 6, 2007, 8:31pm

Glynn,

Paul Kelly sent me this great-sounding tip as a way to get system
information without invoking the Unix command uname, which is unavailable
under windows.

The only problem is that I get an error...

can't read "tcl_platform(platform)": no such variable

...whenever I try to invoke it in a TclTk script. Even odder, if I invoke it
from a wish command line, it is fine (though it report unix on my Mac
because I'm using x11).

Is there some secret trick to using this? It is not apparent in the TclTk
docs that I'm reading.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
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

------ Forwarded Message

From: Paul Kelly <paul-grass@stjohnspoint.co.uk>
Date: Sun, 6 May 2007 05:05:46 +0100 (BST)
To: Michael Barton <michael.barton@asu.edu>
Cc: <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] Problem with font selection in gis.m on Windows

Usually I did platform checking in Tcl by looking for environment
variables that were platform-specific, e.g. something like:
if {[info exists env(OS)] && $env(OS) == "Windows_NT"}
but I see in the new d.rast.edit Glynn has used some kind of Tcl variable
which looks like an even neater way of doing it:
if {$tcl_platform(platform) == "windows"}

------ End of Forwarded Message

Glynn_Clements1 · May 6, 2007, 9:09pm

Michael Barton wrote:

Paul Kelly sent me this great-sounding tip as a way to get system
information without invoking the Unix command uname, which is unavailable
under windows.

The only problem is that I get an error...

can't read "tcl_platform(platform)": no such variable

...whenever I try to invoke it in a TclTk script. Even odder, if I invoke it
from a wish command line, it is fine (though it report unix on my Mac
because I'm using x11).

Is there some secret trick to using this? It is not apparent in the TclTk
docs that I'm reading.

Are you using it from within a procedure? If so, you need to use
"global tcl_platform", as with any other global variable.

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

cmbarton · May 7, 2007, 4:24am

I've fixed this in the CVS, so that setting the default font should work
with Windows now.

Michael

On 5/6/07 2:09 PM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

Michael Barton wrote:

Paul Kelly sent me this great-sounding tip as a way to get system
information without invoking the Unix command uname, which is unavailable
under windows.

The only problem is that I get an error...

can't read "tcl_platform(platform)": no such variable

...whenever I try to invoke it in a TclTk script. Even odder, if I invoke it
from a wish command line, it is fine (though it report unix on my Mac
because I'm using x11).

Is there some secret trick to using this? It is not apparent in the TclTk
docs that I'm reading.

Are you using it from within a procedure? If so, you need to use
"global tcl_platform", as with any other global variable.

__________________________________________
Michael Barton, Professor of Anthropology
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

Paul_Kelly · May 7, 2007, 12:13pm

On Sun, 6 May 2007, Michael Barton wrote:

I've fixed this in the CVS, so that setting the default font should work
with Windows now.

OK thanks I made a few more changes and now it is working quite well. Most notably that the
global env, tcl_platform
syntax didn't work (env(GISBASE) was an unknown variable) and I had to change it to:
global env
global tcl_platform
(which is what the Tcl documentation suggests anyway; ISTR coming across this before but it seemed to be OK then. Not too sure.)

The other noteworthy change was using the Native Tk file browser widget ::tk::dialog::file:: instead of the native Windows one that tk_getOpenFile uses. The native Windows one was very slow and clunky and most importantly didn't work for selecting fonts from the Windows fonts directory. Clicking on a file didn't put it into the selection box and double-clicking opened a Window displaying the font's capabilities. The native Tk widget admittedly has a distinct early-90s look to it but it is fast and (most importantly) works.

Paul

Glynn_Clements1 · May 7, 2007, 2:18pm

Paul Kelly wrote:

> I've fixed this in the CVS, so that setting the default font should work
> with Windows now.

OK thanks I made a few more changes and now it is working quite well. Most
notably that the
global env, tcl_platform
syntax didn't work (env(GISBASE) was an unknown variable) and I had to
change it to:
global env
global tcl_platform

You can specify multiple variables in a single "global" statement, but
there shouldn't be any commas. "global env, tcl_platform" will attempt
to import a variable named "env," (with a trailing comma).

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

cmbarton · May 7, 2007, 3:20pm

Thanks Paul. I'll update my version.

Michael

On 5/7/07 5:13 AM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

On Sun, 6 May 2007, Michael Barton wrote:

I've fixed this in the CVS, so that setting the default font should work
with Windows now.

OK thanks I made a few more changes and now it is working quite well. Most
notably that the
global env, tcl_platform
syntax didn't work (env(GISBASE) was an unknown variable) and I had to
change it to:
global env
global tcl_platform
(which is what the Tcl documentation suggests anyway; ISTR coming across
this before but it seemed to be OK then. Not too sure.)

The other noteworthy change was using the Native Tk file browser widget
::tk::dialog::file:: instead of the native Windows one that tk_getOpenFile
uses. The native Windows one was very slow and clunky and most
importantly didn't work for selecting fonts from the Windows fonts
directory. Clicking on a file didn't put it into the selection box and
double-clicking opened a Window displaying the font's capabilities. The
native Tk widget admittedly has a distinct early-90s look to it but it is
fast and (most importantly) works.

Paul

__________________________________________
Michael Barton, Professor of Anthropology
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

cmbarton · May 7, 2007, 3:26pm

Typo on my part. I'm surprised it work OK for me.

Michael

On 5/7/07 7:18 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

Paul Kelly wrote:

I've fixed this in the CVS, so that setting the default font should work
with Windows now.

OK thanks I made a few more changes and now it is working quite well. Most
notably that the
global env, tcl_platform
syntax didn't work (env(GISBASE) was an unknown variable) and I had to
change it to:
global env
global tcl_platform

You can specify multiple variables in a single "global" statement, but
there shouldn't be any commas. "global env, tcl_platform" will attempt
to import a variable named "env," (with a trailing comma).

__________________________________________
Michael Barton, Professor of Anthropology
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

William_Kyngesburye · May 11, 2007, 12:25am

So, without uname, is there another reliable way on the command line/in a shell script, not in Tcl?

I worked a way to get grass-xterm-wrapper to work with the OSX Terminal.app instead of X11 xterm, but I use uname to check the system so OSX defaults to Terminal.app. It'll still work without that bit, but GRASS_XTERM would need to be explicitly set - no big deal, I can move the default to the OSX startup or init.sh.

On May 6, 2007, at 3:31 PM, Michael Barton wrote:

Glynn,

Paul Kelly sent me this great-sounding tip as a way to get system
information without invoking the Unix command uname, which is unavailable
under windows.

...

Usually I did platform checking in Tcl by looking for environment
variables that were platform-specific, e.g. something like:
if {[info exists env(OS)] && $env(OS) == "Windows_NT"}
but I see in the new d.rast.edit Glynn has used some kind of Tcl variable
which looks like an even neater way of doing it:
if {$tcl_platform(platform) == "windows"}

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"I ache, therefore I am. Or in my case - I am, therefore I ache."

- Marvin

H_B · May 11, 2007, 4:30am

William Kyngesburye wrote:

So, without uname, is there another reliable way on the command line/
in a shell script, not in Tcl?

I worked a way to get grass-xterm-wrapper to work with the OSX
Terminal.app instead of X11 xterm, but I use uname to check the
system so OSX defaults to Terminal.app. It'll still work without
that bit, but GRASS_XTERM would need to be explicitly set - no big
deal, I can move the default to the OSX startup or init.sh.

AFAIU it's only on native Windows where uname is a problem. It's fine on
BSD/OSX. grass-xterm-wrapper is explicitly a #!/bin/sh script, so using
UNIXisms inside that is not a problem. Or another way, native Windows
can't use the grass-xterm-wrapper script anyway.

Hamish