Details Ticket 4960


Comment | Reply | Take | Resolve


Serial Number 4960
Subject gis.m has menu entries for nonexisting modules
Area grass6
Queue grass
Requestors maris.gis@gmail.com
Owner none
Status open
Last User Contact Fri Aug 4 08:19:59 2006 (2 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Fri Aug 4 08:19:59 2006 (2 yr ago)
Created Thu Aug 3 13:52:39 2006 (2 yr ago)

Transaction History Ticket 4960


Thu, Aug 3 2006 13:52:39    Request created by guest  
Subject: gis.m has menu entries for nonexisting modules

Platform: GNU/Linux/x86
grass obtained from: Trento Italy site
grass binary for platform: Compiled from Sources
GRASS Version: 6.1.0RC1

gis.m menus contain menu entries for modules which are missing for some 
reason.

i.e. if I compile grass without C++, I don't have r.terraflow, but I sill 
will have menu entry for it.

Couldn't there be something like script which runs after all module 
compilation (before make install?) and masks unavailable module entries? 
Logic like "if (! `ls dist.i686-pc-linux-gnu/bin | grep 
menu.tcl.module["foo"]`) then disable(comment out)". As I'm not scripting 
guru, I can't write such script.
Thu, Aug 3 2006 20:10:41    Mail sent by michael.barton@asu.edu  
Return-Path <michael.barton@asu.edu>
Delivered-To grass-bugs@lists.intevation.de
User-Agent Microsoft-Entourage/11.2.5.060620
Date Thu, 03 Aug 2006 11:12:15 -0700
Subject Re: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for nonexisting modules
From Michael Barton <michael.barton@asu.edu>
To Paolo Cavallini via RT <grass-bugs@intevation.de>, <grass-dev@grass.itc.it>
Message-ID <C0F78A8F.23326%michael.barton@asu.edu>
Thread-Topic [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for nonexisting modules
Thread-Index Aca3KFk3l/ybAiMbEdu8AAAUUSYxwg==
In-Reply-To <20060803115239.EE603101EE6@lists.intevation.de>
Mime-version 1.0
Content-type text/plain; charset="US-ASCII"
Content-transfer-encoding 7bit
X-Virus-Scanned by amavisd-new
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-2.605 tagged_above=-999 required=3 tests=[AWL=1.047, BAYES_00=-5, RCVD_NUMERIC_HELO=1.348]
X-Spam-Level
This should be a wish, not a bug.

Nice idea to have autogenerated menus. I've floated it a time or two and
others have mentioned it too. Maybe someone knows how to do it.

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

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


> From: Request Tracker <grass-bugs@intevation.de>
> Reply-To: Request Tracker <grass-bugs@intevation.de>
> Date: Thu,  3 Aug 2006 13:52:39 +0200 (CEST)
> To: <grass-dev@grass.itc.it>
> Subject: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for
> nonexisting modules
> 
> this bug's URL: http://intevation.de/rt/webrt?serial_num=4960
> -------------------------------------------------------------------------
> 
> Subject: gis.m has menu entries for nonexisting modules
> 
> Platform: GNU/Linux/x86
> grass obtained from: Trento Italy site
> grass binary for platform: Compiled from Sources
> GRASS Version: 6.1.0RC1
> 
> gis.m menus contain menu entries for modules which are missing for some
> reason.
> 
> i.e. if I compile grass without C++, I don't have r.terraflow, but I sill
> will have menu entry for it.
> 
> Couldn't there be something like script which runs after all module
> compilation (before make install?) and masks unavailable module entries?
> Logic like "if (! `ls dist.i686-pc-linux-gnu/bin | grep
> menu.tcl.module["foo"]`) then disable(comment out)". As I'm not scripting
> guru, I can't write such script.
> 
> -------------------------------------------- Managed by Request Tracker
> 
> 


Thu, Aug 3 2006 22:23:30    Mail sent by tutey@o2.pl  
Return-Path <tutey@o2.pl>
Delivered-To grass-bugs@lists.intevation.de
Message-ID <44D25B3E.9040901@o2.pl>
Date Thu, 03 Aug 2006 22:23:26 +0200
From Maciej Sieczka <tutey@o2.pl>
User-Agent Thunderbird 1.5.0.5 (X11/20060728)
MIME-Version 1.0
To Michael Barton <michael.barton@asu.edu>
Cc grass-bugs@intevation.de, grass-dev@grass.itc.it
Subject Re: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for nonexisting modules
References <C0F78A8F.23326%michael.barton@asu.edu>
In-Reply-To <C0F78A8F.23326%michael.barton@asu.edu>
Content-Type text/plain; charset=ISO-8859-1
Content-Transfer-Encoding 8bit
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-4.729 tagged_above=-999 required=3 tests=[AWL=0.005, BAYES_00=-5, FORGED_RCVD_HELO=0.266]
X-Spam-Level
Michael Barton napisa?(a):
> This should be a wish, not a bug.

No, it shouldn't be a wish only because we don't know how to fix it
currently.

All the user knows is that he selects an entry in the gis.m or d.m and
he gets "command not found" or whatever other error. It is a bug for
him. For me too.

> Nice idea to have autogenerated menus. I've floated it a time or two and
> others have mentioned it too. Maybe someone knows how to do it.

I'm not trying to be wise ass or whatever. I don't know too. Just let's
not pretend bugs are not bugs.

Maciek


Thu, Aug 3 2006 22:29:00    Comments added by guest  
It is bug:
Joe AverageUser clicks on menu item and gets "ERROR balhblahblah..." If he 
gets "Sorry, Your GRASS version lacks such feature", then it is OK, but 
currently it IS bug.

Autogenerated or at least autocleaned menu is one of possible solutions and,
yes, it may be considered as wish.

How about quick'n'dirty fix like this? (My first 3 lines in tcl/tk)

--- gui/tcltk/gis.m/runandoutput.tcl.orig       2006-07-22 
12:29:48.000000000 +0300
+++ gui/tcltk/gis.m/runandoutput.tcl    2006-08-03 23:09:43.000000000 +0300
@@ -65,10 +65,15 @@
 }
 
 proc run_ui {cmd} {
-    global dlg path
+    global dlg path env
 
     set program [lindex $cmd 0]
 
+    if { ![file executable $env(GISBASE)/bin/$program] }  {
+      tk_messageBox -icon error -message [G_msg "Sorry, your GRASS 
installation lacks module \"$program\""]
+      return
+    }
+
     set code [exec -- $program --tcltk]
 
     set path .dialog$dlg
Fri, Aug 4 2006 00:29:25    Mail sent by glynn@gclements.plus.com  
Return-Path <glynn@gclements.plus.com>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn@gclements.plus.com>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <17618.30312.776595.151987@cerise.gclements.plus.com>
Date Thu, 3 Aug 2006 23:19:20 +0100
To Michael Barton <michael.barton@asu.edu>
Cc Paolo Cavallini via RT <grass-bugs@intevation.de>, <grass-dev@grass.itc.it>
Subject Re: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for nonexisting modules
In-Reply-To <C0F78A8F.23326%michael.barton@asu.edu>
References <20060803115239.EE603101EE6@lists.intevation.de> <C0F78A8F.23326%michael.barton@asu.edu>
X-Mailer VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-3.614 tagged_above=-999 required=3 tests=[AWL=1.120, BAYES_00=-5, FORGED_RCVD_HELO=0.266]
X-Spam-Level
Michael Barton wrote:

> > gis.m menus contain menu entries for modules which are missing for some
> > reason.
> > 
> > i.e. if I compile grass without C++, I don't have r.terraflow, but I sill
> > will have menu entry for it.
> > 
> > Couldn't there be something like script which runs after all module
> > compilation (before make install?) and masks unavailable module entries?
> > Logic like "if (! `ls dist.i686-pc-linux-gnu/bin | grep
> > menu.tcl.module["foo"]`) then disable(comment out)". As I'm not scripting
> > guru, I can't write such script.
> 
> This should be a wish, not a bug.

Actually, I'm not sure that it should even be a wish.

Leaving the menu entry in place lets the user know that certain
functionality is "available", even if they have to get a newer version
or compile GRASS themselves. If the menu entry is simply omitted, they
won't even consider that option.

Also, testing whether an executable is present isn't the same thing as
testing whether or not it can actually be run. It's arguably better to
treat all such problems in a similar manner (attempt to run the module
and show any specific errors to the user) than to treat specially the
case where the executable is absent.

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


Fri, Aug 4 2006 00:38:08    Mail sent by michael.barton@asu.edu  
Return-Path <michael.barton@asu.edu>
Delivered-To grass-bugs@lists.intevation.de
User-Agent Microsoft-Entourage/11.2.5.060620
Date Thu, 03 Aug 2006 15:39:46 -0700
Subject Re: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for nonexisting modules
From Michael Barton <michael.barton@asu.edu>
To Glynn Clements <glynn@gclements.plus.com>
Cc Paolo Cavallini via RT <grass-bugs@intevation.de>, <grass-dev@grass.itc.it>
Message-ID <C0F7C942.23346%michael.barton@asu.edu>
Thread-Topic [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for nonexisting modules
Thread-Index Aca3Tbhb9urlFiNAEdu8AAAUUSYxwg==
In-Reply-To <17618.30312.776595.151987@cerise.gclements.plus.com>
Mime-version 1.0
Content-type text/plain; charset="US-ASCII"
Content-transfer-encoding 7bit
X-Virus-Scanned by amavisd-new
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-2.615 tagged_above=-999 required=3 tests=[AWL=1.037, BAYES_00=-5, RCVD_NUMERIC_HELO=1.348]
X-Spam-Level
Good points.

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

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


> From: Glynn Clements <glynn@gclements.plus.com>
> Date: Thu, 3 Aug 2006 23:19:20 +0100
> To: Michael Barton <michael.barton@asu.edu>
> Cc: Paolo Cavallini via RT <grass-bugs@intevation.de>,
> <grass-dev@grass.itc.it>
> Subject: Re: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for
> nonexisting modules
> 
> 
> Michael Barton wrote:
> 
>>> gis.m menus contain menu entries for modules which are missing for some
>>> reason.
>>> 
>>> i.e. if I compile grass without C++, I don't have r.terraflow, but I sill
>>> will have menu entry for it.
>>> 
>>> Couldn't there be something like script which runs after all module
>>> compilation (before make install?) and masks unavailable module entries?
>>> Logic like "if (! `ls dist.i686-pc-linux-gnu/bin | grep
>>> menu.tcl.module["foo"]`) then disable(comment out)". As I'm not scripting
>>> guru, I can't write such script.
>> 
>> This should be a wish, not a bug.
> 
> Actually, I'm not sure that it should even be a wish.
> 
> Leaving the menu entry in place lets the user know that certain
> functionality is "available", even if they have to get a newer version
> or compile GRASS themselves. If the menu entry is simply omitted, they
> won't even consider that option.
> 
> Also, testing whether an executable is present isn't the same thing as
> testing whether or not it can actually be run. It's arguably better to
> treat all such problems in a similar manner (attempt to run the module
> and show any specific errors to the user) than to treat specially the
> case where the executable is absent.
> 
> -- 
> Glynn Clements <glynn@gclements.plus.com>


Fri, Aug 4 2006 08:19:59    Mail sent by michael.barton@asu.edu  
Return-Path <michael.barton@asu.edu>
Delivered-To grass-bugs@lists.intevation.de
User-Agent Microsoft-Entourage/11.2.5.060620
Date Thu, 03 Aug 2006 23:19:51 -0700
Subject Re: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for nonexisting modules
From Michael Barton <michael.barton@asu.edu>
To Maciej Sieczka <tutey@o2.pl>
Cc Paolo Cavallini via RT <grass-bugs@intevation.de>, <grass-dev@grass.itc.it>
Message-ID <C0F83517.D07B%michael.barton@asu.edu>
Thread-Topic [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for nonexisting modules
Thread-Index Aca3jf44PH+9WiOBEdu2FQAKlXAweg==
In-Reply-To <44D25B3E.9040901@o2.pl>
Mime-version 1.0
Content-type text/plain; charset="US-ASCII"
Content-transfer-encoding 7bit
X-Virus-Scanned by amavisd-new
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-3.086 tagged_above=-999 required=3 tests=[AWL=0.566, BAYES_00=-5, RCVD_NUMERIC_HELO=1.348]
X-Spam-Level
Maciek,

What goes into the menu at the moment is what is a standard, complete (not
minimal) GRASS installation, AFAICT. I try to leave out things that are not
normally compiled and modules that require the installation of a separate
program that does not come with GRASS (I used to leave out r.out.gdal, for
example, but GDAL is now a required dependency and it is on the menu).
However, this does not account for someone who compiles GRASS and decides
not to include some module. Nor can it easily do so. Also, other people
besides me also add to the menu occasionally, and I may miss what is a
standard, complete install--especially given the rapidly changing state of
the program. 

A new program to autogenerate a menu based on what a user decides to compile
is a new feature; its lack is not a bug. In fact, it is more accurate to
treat the missing feature as a bug than the non-functional menu item for it.
Unless someone else writes a program to automatically generate a
menu--probably requiring significant reorganization of the menu system--it
is not going to happen anytime soon. In the long run, it's worthwhile to
have such a system to better keep up with GRASS development. But probably it
won't really be feasible to consider such a system until the switch to a new
GUI development platform, like wxPython, where GUI descriptors and menus can
be stored in XML format. I also agree with the sentiment of Glynn's
comments. There should be a standard GUI for a standard GRASS installation.
I menu item that doesn't do anything signals that the program is not
complete, not that the menu is faulty.

I appreciate your perspective on this. However, there are more than enough
bugs of things that are actually broken to keep us all busy. But that
doesn't mean that we should keep open to ways to improve the program too.

Cheers
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



> From: Maciej Sieczka <tutey@o2.pl>
> Date: Thu, 03 Aug 2006 22:23:26 +0200
> To: Michael Barton <michael.barton@asu.edu>
> Cc: <grass-bugs@intevation.de>, <grass-dev@grass.itc.it>
> Subject: Re: [GRASS-dev] [bug #4960] (grass) gis.m has menu entries for
> nonexisting modules
> 
> Michael Barton napisa?(a):
>> This should be a wish, not a bug.
> 
> No, it shouldn't be a wish only because we don't know how to fix it
> currently.
> 
> All the user knows is that he selects an entry in the gis.m or d.m and
> he gets "command not found" or whatever other error. It is a bug for
> him. For me too.
> 
>> Nice idea to have autogenerated menus. I've floated it a time or two and
>> others have mentioned it too. Maybe someone knows how to do it.
> 
> I'm not trying to be wise ass or whatever. I don't know too. Just let's
> not pretend bugs are not bugs.
> 
> Maciek
> 
> 


Comment | Reply | Take | Resolve

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request