On Feb 27, 2008, at 1:47 AM, grass-dev-request@lists.osgeo.org wrote:
Date: Wed, 27 Feb 2008 02:08:14 -0000
From: "GRASS GIS" <trac@osgeo.org>
Subject: [GRASS-dev] [GRASS GIS] #70: i.target from GUI: strip @mapset
part
To: undisclosed-recipients:;
Message-ID: <040.2d24057011b5108d92306c223fc7f99a@osgeo.org>
Content-Type: text/plain; charset="utf-8"#70: i.target from GUI: strip @mapset part
---------------------+------------------------------------------------------
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: minor | Milestone: 6.4.0
Component: default | Version: svn-trunk
Keywords: |
---------------------+------------------------------------------------------
Hi,if you call i.target from a GUI and select a group it appends @mapset. If
you run it like that it takes the full name literally and instead of
updating the group's target it creates a new group of name "group@mapset".
Either i.target or I_put_target() should check that if the @mapset part is
given it refers to the current mapset, then strip off the @mapset part.Otherwise you end up with
{{{
GRASS> g.list groupgroup
group@mapset
group@mapset@mapsetetc.
}}}I changed the group option gisprompt from old,group,group to any,gr,gr.
This makes the GUI group picker button go away, but perhaps the GUI picker
button should be coded to remain in that case?Or to solve this should we try changing the gisprompt to mapset,gr,gr so
it calls G_ask_in_mapset()?
The GUI uses the global $GISBASE/etc/element.list to ID parsable element types. "gr" is not in the list (unless you've added it since last night). So it isn't parsed by the GUI. To solve this at the GUI level, we would need to changed the command parsers (in TclTk and wxPython) to either 1) read all "group" elements without "@mapset" or 2) create a new element that represents a "group" without "@mapset" (e.g. "gr") and specify how and where it should be parsed.
From the thread about this that I started a couple weeks ago, there seem to be some difference of opinion on how to fix the issues about reading "@mapset". This can be dealt with in the GUI for the specific cases where it's a problem. However, Glynn's point (I hope I'm summarizing this correctly) is that this is a problem at the module level and should be solved there instead of stripping out the "@mapset" at the GUI level. I think we need to get this settled so we can decide where to start fixing things.
Michael