[GRASS-dev] Re: grass-dev Digest, Vol 21, Issue 1

GRASS GIS GRASS GIS developer
1

On Jan 1, 2008, at 3:13 AM, grass-dev-request@lists.osgeo.org wrote:

#12: gis.m->Help->About system doesn’t work (launches another gis.m instance)

----------------------±----------------------------------------------------

Reporter: neteler | Owner: grass-dev@lists.osgeo.org

Type: defect | Status: new

Priority: major | Milestone: 6.3.0

Component: default | Version: unspecified

Resolution: | Keywords:

----------------------±----------------------------------------------------

Comment (by cmbarton):

Replying to [ticket:12 neteler]:

Clicking on ‘About System’ within the gis.m Help menu launches a new set

of gis.m windows instead of opening a tcl/tk window with system

parameters. The newly created gis manager toolbar says "Tk System

Information".

PS: moved here from

http://wald.intevation.org/tracker/?func=detail&atid=204&aid=553&group_id=21

Is this function worth the trouble of trying to fix?

This is just a symptom of a larger problem, namely that the Gm::errmsg

procedure is defined in gm.tcl, which cannot be "source"d (because

doing so will “run” gis.m).

Gm::errmsg belongs in a “library”, i.e. a Tcl source file which can be

"source"d from other Tcl source files.

Also: gm.tcl calls Gm::errmsg from top-level code at the beginning of

the file (the code which copies various g.gisenv settings into $env),

although the procedure isn’t actually defined until much later in the

file. If any of those “catch” statements actually catch an error, the

handler will throw an error due to Gm::errmsg being undefined.

Making a library and moving Gm::errmsg to it is pretty easy to fix (just a LOT of find/replace throughout the GUI code). Anything else that you know of should come out of gm.tcl and into such a library?

However, making the ‘get system info’ function work is more trouble. As I said in the rest of the post, it’s very old code. Is it worth bothering with to have the GUI launch a window with a bit of minimal system info?

Michael

C. 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-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>

2

>> #12: gis.m->Help->About system doesn't work (launches another
>> gis.m instance)
>> +-----------------------------------------------------

Michael Barton wrote:

As I said in the rest of the post, it's very old code. Is it worth
bothering with to have the GUI launch a window with a bit of minimal
system info?

Its primary use, AFAICT, is to help give the GUI devels extra info to
go along with user supplied debugging reports.

Hamish

      ____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping

3

Sounds like we don't really need this then. Anyone object to me getting rid of this menu entry?

Michael
______________________________
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

On Jan 1, 2008, at 2:14 PM, Hamish wrote:

#12: gis.m->Help->About system doesn't work (launches another
gis.m instance)
+-----------------------------------------------------

Michael Barton wrote:

As I said in the rest of the post, it's very old code. Is it worth
bothering with to have the GUI launch a window with a bit of minimal
system info?

Its primary use, AFAICT, is to help give the GUI devels extra info to
go along with user supplied debugging reports.

Hamish

     ____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping

4

Sounds like we don't really need this then. Anyone object to me
getting rid of this menu entry?

Michael

Not me. I never have need for this feature. Hints for augmenting bug reports with system info can just be added to the bug reporting section of the WIKI if need be.

~ Eric.

5

IMHO this feature should be removed for now, still there could be some
bug reporting feature in GUI, that could collect some essential info
for bug reports like OS, arch, version, tcl/tk/python version,
g.region info etc. to help new users with bug reports. Today first
replay to many bug reports is "version? OS?" etc. and this could be
avoided by providing some copy/paste info for better bugreports.

Just my 0.002,
Maris.

2008/1/3, Patton, Eric <epatton@nrcan.gc.ca>:

>Sounds like we don't really need this then. Anyone object to me
>getting rid of this menu entry?

>Michael

Not me. I never have need for this feature. Hints for augmenting bug reports
with system info can just be added to the bug reporting section of the WIKI
if need be.

~ Eric.

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

6

Michael Barton wrote:

> Gm::errmsg belongs in a "library", i.e. a Tcl source file which can be
> "source"d from other Tcl source files.
>
> Also: gm.tcl calls Gm::errmsg from top-level code at the beginning of
> the file (the code which copies various g.gisenv settings into $env),
> although the procedure isn't actually defined until much later in the
> file. If any of those "catch" statements actually catch an error, the
> handler will throw an error due to Gm::errmsg being undefined.

Making a library and moving Gm::errmsg to it is pretty easy to fix
(just a LOT of find/replace throughout the GUI code). Anything else
that you know of should come out of gm.tcl and into such a library?

One option is to make gm.tcl the library and put the gis.m "main" in a
different file. The function would still be called Gm::errmsg.

Everything up to the "proc Gm::create" line should probably be in a
library, while the stuff following is specific to the gis.m
application.

However, making the 'get system info' function work is more trouble.
As I said in the rest of the post, it's very old code. Is it worth
bothering with to have the GUI launch a window with a bit of minimal
system info?

It might be useful for dealing with gis.m bug reports.

AFAICT, the only reason it stopped working was the botched conversion
to using Gm:errmsg.

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

7

Patton, Eric wrote:

>Sounds like we don't really need this then. Anyone object to me
>getting rid of this menu entry?

>Michael

Not me. I never have need for this feature. Hints for augmenting bug
reports with system info can just be added to the bug reporting
section of the WIKI if need be.

How is the user supposed to get that information?

Asking the user to run tclsh manually and get the contents of
$tcl_platform introduces a risk that they might run the wrong tclsh
(quite easily done on Windows and MacOSX systems, where you may have
both "native" and "Unix" versions of Tcl/Tk installed).

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

8

Patton, Eric wrote:

>Sounds like we don't really need this then. Anyone object to me
>getting rid of this menu entry?

>Michael

Not me. I never have need for this feature. Hints for augmenting bug
reports with system info can just be added to the bug reporting
section of the WIKI if need be.

How is the user supposed to get that information?

Asking the user to run tclsh manually and get the contents of
$tcl_platform introduces a risk that they might run the wrong tclsh
(quite easily done on Windows and MacOSX systems, where you may have
both "native" and "Unix" versions of Tcl/Tk installed).

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

Couldn't that information be supplied through standard Unix commands
(asking out of ignorance, I don't really know)?

I don't think I've ever seen an instance where the output from
'About System' has ever been used in a bug report; not that it couldn't,
of course.

~ Eric.
a bug report

9

Patton, Eric wrote:

> >Sounds like we don't really need this then. Anyone object to me
> >getting rid of this menu entry?
>
> >Michael
>
> Not me. I never have need for this feature. Hints for augmenting bug
> reports with system info can just be added to the bug reporting
> section of the WIKI if need be.

>How is the user supposed to get that information?

>Asking the user to run tclsh manually and get the contents of
>$tcl_platform introduces a risk that they might run the wrong tclsh
>(quite easily done on Windows and MacOSX systems, where you may have
>both "native" and "Unix" versions of Tcl/Tk installed).

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

Couldn't that information be supplied through standard Unix commands
(asking out of ignorance, I don't really know)?

There are Unix commands which will obtain information about the
system. But they won't provide information about Tcl/Tk itself, nor
about Tcl's "perspective" of the system (e.g. if you compile the
Unix/X11 version of Tcl/Tk for Cygwin, $tcl_platform(platform) will be
"unix", whereas for a native version it will be "windows".

If there are problems with gis.m, then it's the Tcl information which
really matters.

I don't think I've ever seen an instance where the output from
'About System' has ever been used in a bug report; not that it couldn't,
of course.

I wouldn't expect the information to be "volunteered", but it may be
useful to be able to ask the user to provide this information without
having to provide long, complex and error-prone instructions on how to
obtain it.

In that regard, it's important that the information is displayed in
such a way that it can easily be copied into an email message (i.e.
display it in a text widget, not a label).

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