Mon, Feb 7 2005
00:40:16
|
|
Request created by guest
|
|
Subject: v.type GUI bug
Platform: GNU/Linux/i386
grass obtained from: Mirror of Trento site
grass binary for platform: Compiled from Sources
GRASS Version: grass-6.0.cvs_src_snapshot_2005_01_22
v.type GUI is not usable: you can specify the input geometry and output geometry
only one way - eg. the sequence is always 'type=point,centroid' and it can't
be set to 'type=centroid,point' (unless you go to command line).
Maciek |
|
Tue, Apr 19 2005
22:28:22
|
|
Comments added by guest
|
|
Cc: michael.barton@asu.edu
The bug still remains. Is it possible to do something about it Michael?
I recall there is some other command(s) where this issue apply.
Maciek |
|
Fri, Sep 2 2005
18:36:57
|
|
User changed to werchowyna@epf.pl by msieczka
|
|
Fri, Sep 2 2005
18:37:02
|
|
Area changed to grass6 by msieczka
|
|
Fri, Jul 7 2006
16:45:35
|
|
Owner changed to cshock by mneteler
|
|
Fri, Jul 7 2006
16:45:35
|
|
Mail sent by mneteler
|
|
Hi,
maybe Cedric can help?
Markus |
|
Sat, Jul 15 2006
21:16:40
|
|
Untaken by cshock
|
|
Sat, Jul 15 2006
21:16:40
|
|
Mail sent by cshock
|
|
The options type is interpreted by the gui as being a set of boolean values
(thus the checkboxes). This is how it's used in many other modules, such as
d.vect.
v.type assumes a different semantic meaning to options (a type safe enumerated
list) and relies heavily on the behaviour of the options implementation for
error safety and parsing (I have no quick fix).
There is probably a hack fix like the following: declare the parser.c option
of v.type to be a regular text (not option) option. After parser.c has handed
back the options structure hand jsut this option (possibly with its type
modified) back to whatever parser.c "function" parses the list of options as-is.
The correct fix is to either add another semantic meaning to the parser system
for a type safe enumerated list or to copy the code that does this into v.type. |
|
Wed, Jul 26 2006
14:22:03
|
|
User changed to tutey@o2.pl by msieczka
|
|
Wed, May 23 2007
07:47:37
|
|
Comments added by hbowman
|
|
From: Hamish
Subject: Re: [GRASS-dev] [bug #2969] can wxPython GUI handle order of options
for v.type and alike?
Date: Wed, 23 May 2007 17:27:15 +1200
To: grass-dev ta grass itc it
> Maciej Sieczka wrote:
> > I was wondering if the wxPython GUI is going to deal with problems
> > the tcl/tk GUI can't - when there is a set of pre-defined parameters
> > to choose from and the user should be able to decide about the order
> > of them.
> >
> > An example is v.type [1], for which in the tcl/tk GUI you can
> > specify the order of types only one way, eg. 'type=point,centroid',
> > but 'type=centroid,point' is impossible to achieve.
> >
> > [1]http://intevation.de/rt/webrt?serial_num=2969
>
Hamish:
> maybe use a wrapper script that has the possible combinations as
> flags?
>
> [ ] point -> centroid
> [*] centroid -> point
> [ ] line -> boundary
> [ ] boundary -> line
>
> standy by.. I'll write one.
gui/tcltk/gis.m/script/v.type.sh
added in 6.3cvs + Tcl gui menu updated. I'll backport to 6.2 if others
report success. The help page link disappears, but the v.type help
page isn't much to read anyway. Uses /bin/sh, so not for native Windows.
to keep the option list short, point->kernel etc. are not supported
directly, you have to go point->centroid, centroid->kernel.
I notice a small bug in the GUI module window. After selecting an item
from a pulldown list, it doesn't visually update the command line string
along the bottom until you click something else. Clicking [Run] or
[Copy] updates it, so no functional error, but it would be nice if that
could be refreshed by the menu selection process. (tcl tk 8.3)
Hamish
_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev
|
|
Fri, Jul 25 2008
16:38:03
|
|
Status changed to resolved by msieczka
|
|
Fri, Jul 25 2008
16:38:02
|
|
Mail sent by msieczka
|
|
The issue has been moved to Trac http://trac.osgeo.org/grass/ticket/234. |
|