Re: [GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
--+-
  Reporter:  pvanbosgeo   |   Owner:  grass-dev@… 
  Type:  enhancement  |  Status:  closed  
  Priority:  normal   |   Milestone:  7.0.1   
 Component:  Default  | Version:  unspecified 
Resolution:  fixed|Keywords:  g.list, g.remove, g.mlist, g.mremove
  Platform:  All  | Cpu:  Unspecified 
--+-
Changes (by wenzeslaus):

  * status:  new => closed
  * resolution:  => fixed
  * milestone:  7.1.0 => 7.0.1


Comment:

 Original issue is solved and the interface changed for 7.0.0.

 Closing. (Trac forces milestone 7.0.1 but this should have been closed for
 7.0.0.)

 Open a new ticket if you have further concerns.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
--+-
 Reporter:  pvanbosgeo|   Owner:  grass-dev@…   
   
 Type:  enhancement   |  Status:  new   
   
 Priority:  normal|   Milestone:  7.1.0 
   
Component:  Default   | Version:  unspecified   
   
 Keywords:  g.list, g.remove, g.mlist, g.mremove  |Platform:  All   
   
  Cpu:  Unspecified   |  
--+-

Comment(by mlennert):

 Replying to [comment:29 annakrat]:
 > Replying to [comment:28 hcho]:
 > > Replying to [comment:27 mlennert]:
 > > > Replying to [comment:26 annakrat]:
 > > > > I am generally against implementing any special things for one
 module (which has autogenerated dialog).
 > > >
 > > > +1
 > > >
 > > > Moritz
 > >
 > > Yeah.. +1 too. What about just getting rid of that flag completely and
 using g.list instead? While updating python scripts, I found it's just too
 much typing to add flags="f" every time and it doesn't make much sense in
 scripting anyway. Since the API of g.remove is compatible with g.list API
 as far as search patterns are concerned, it's a matter of changing module
 names. Is it too dangerous?
 >
 > I am afraid it is. Especially when users are used to it from the
 previous interface. Using -f flag only when using pattern/exclude would
 make more sense if want to avoid using it every time, but I understand why
 you don't like it. Some more input from others would be appreciated...

 I don't mind having the -f flag as extra security, even though it does add
 typing an extra 3 characters to the former use of g.remove.

 +1 for keeping the -f for all types of map selection.


 Moritz

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
--+-
 Reporter:  pvanbosgeo|   Owner:  grass-dev@…   
   
 Type:  enhancement   |  Status:  new   
   
 Priority:  normal|   Milestone:  7.1.0 
   
Component:  Default   | Version:  unspecified   
   
 Keywords:  g.list, g.remove, g.mlist, g.mremove  |Platform:  All   
   
  Cpu:  Unspecified   |  
--+-

Comment(by annakrat):

 Replying to [comment:28 hcho]:
 > Replying to [comment:27 mlennert]:
 > > Replying to [comment:26 annakrat]:
 > > > I am generally against implementing any special things for one
 module (which has autogenerated dialog).
 > >
 > > +1
 > >
 > > Moritz
 >
 > Yeah.. +1 too. What about just getting rid of that flag completely and
 using g.list instead? While updating python scripts, I found it's just too
 much typing to add flags="f" every time and it doesn't make much sense in
 scripting anyway. Since the API of g.remove is compatible with g.list API
 as far as search patterns are concerned, it's a matter of changing module
 names. Is it too dangerous?

 I am afraid it is. Especially when users are used to it from the previous
 interface. Using -f flag only when using pattern/exclude would make more
 sense if want to avoid using it every time, but I understand why you don't
 like it. Some more input from others would be appreciated...

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
--+-
 Reporter:  pvanbosgeo|   Owner:  grass-dev@…   
   
 Type:  enhancement   |  Status:  new   
   
 Priority:  normal|   Milestone:  7.1.0 
   
Component:  Default   | Version:  unspecified   
   
 Keywords:  g.list, g.remove, g.mlist, g.mremove  |Platform:  All   
   
  Cpu:  Unspecified   |  
--+-

Comment(by hcho):

 Replying to [comment:27 mlennert]:
 > Replying to [comment:26 annakrat]:
 > > I am generally against implementing any special things for one module
 (which has autogenerated dialog).
 >
 > +1
 >
 > Moritz

 Yeah.. +1 too. What about just getting rid of that flag completely and
 using g.list instead? While updating python scripts, I found it's just too
 much typing to add flags="f" every time and it doesn't make much sense in
 scripting anyway. Since the API of g.remove is compatible with g.list API
 as far as search patterns are concerned, it's a matter of changing module
 names. Is it too dangerous?

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
--+-
 Reporter:  pvanbosgeo|   Owner:  grass-dev@…   
   
 Type:  enhancement   |  Status:  new   
   
 Priority:  normal|   Milestone:  7.1.0 
   
Component:  Default   | Version:  unspecified   
   
 Keywords:  g.list, g.remove, g.mlist, g.mremove  |Platform:  All   
   
  Cpu:  Unspecified   |  
--+-

Comment(by mlennert):

 Replying to [comment:26 annakrat]:
 > I am generally against implementing any special things for one module
 (which has autogenerated dialog).

 +1

 Moritz

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
--+-
 Reporter:  pvanbosgeo|   Owner:  grass-dev@…   
   
 Type:  enhancement   |  Status:  new   
   
 Priority:  normal|   Milestone:  7.1.0 
   
Component:  Default   | Version:  unspecified   
   
 Keywords:  g.list, g.remove, g.mlist, g.mremove  |Platform:  All   
   
  Cpu:  Unspecified   |  
--+-

Comment(by annakrat):

 Replying to [comment:25 hcho]:
 >
 > > Another suggestion is to use -f only for pattern option. When using
 names, it wouldn't require force flag for the actual removing of the maps.
 Any opinion on that?
 >
 > IMO, that's not a good idea because of inconsistent behaviors. If we
 want any confirmation when using patterns, the force flag should be used
 if "any" of {{{pattern=}}} or {{{exclude=}}} is used.
 > {{{
 > # Patterns used => use -f flag
 > g.remove -f rast pattern=... exclude=...
 > g.remove -f rast pattern=... ignore=...
 > g.remove -f rast names=... exclude=...
 >
 > # No patterns used => no -f flag; this is inconsistent and can be
 confusing when using patterns.
 > g.remove rast names=... ignore=...
 > }}}
 >

 I mostly agree, although inconsistent doesn't necessarily mean not
 intuitive.

 > If it's annoying to run g.remove GUI twice, what about this? In a single
 GUI run, show output and ask the user if they want to delete them.

 I am generally against implementing any special things for one module
 (which has autogenerated dialog).

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
--+-
 Reporter:  pvanbosgeo|   Owner:  grass-dev@…   
   
 Type:  enhancement   |  Status:  new   
   
 Priority:  normal|   Milestone:  7.1.0 
   
Component:  Default   | Version:  unspecified   
   
 Keywords:  g.list, g.remove, g.mlist, g.mremove  |Platform:  All   
   
  Cpu:  Unspecified   |  
--+-

Comment(by hcho):

 Replying to [comment:24 annakrat]:
 > I changed the layout in r62405. I moved options names, type and flag -f
 into one guisection Basic. Some feedback is welcome.
 >
 > Also, do we really need option ignore? Isn't exclude option enough?
 >

 Just like {{{pattern=}}} and {{{names=}}}, {{{exclude=}}} takes a glob or
 regex pattern while {{{ignore=}}} takes a list of names. For example,
 {{{exclude=a?}}} and {{{ignore=a?}}} are different. {{{ignore=a?}}} is
 expanded to a glob pattern {{{a\?}}}. Also, in GUI, multiple map selection
 cannot be supported for {{{exclude=}}} (a single string option), which was
 the main reason why {{{names=}}} and {{{ignore=}}} were added initially. I
 think both {{{names=}}} and {{{ignore=}}} are useful in GUI.

 > Another suggestion is to use -f only for pattern option. When using
 names, it wouldn't require force flag for the actual removing of the maps.
 Any opinion on that?

 IMO, that's not a good idea because of inconsistent behaviors. If we want
 any confirmation when using patterns, the force flag should be used if
 "any" of {{{pattern=}}} or {{{exclude=}}} is used.
 {{{
 # Patterns used => use -f flag
 g.remove -f rast pattern=... exclude=...
 g.remove -f rast pattern=... ignore=...
 g.remove -f rast names=... exclude=...

 # No patterns used => no -f flag; this is inconsistent and can be
 confusing when using patterns.
 g.remove rast names=... ignore=...
 }}}

 If it's annoying to run g.remove GUI twice, what about this? In a single
 GUI run, show output and ask the user if they want to delete them.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
--+-
 Reporter:  pvanbosgeo|   Owner:  grass-dev@…   
   
 Type:  enhancement   |  Status:  new   
   
 Priority:  normal|   Milestone:  7.1.0 
   
Component:  Default   | Version:  unspecified   
   
 Keywords:  g.list, g.remove, g.mlist, g.mremove  |Platform:  All   
   
  Cpu:  Unspecified   |  
--+-

Comment(by annakrat):

 I changed the layout in r62405. I moved options names, type and flag -f
 into one guisection Basic. Some feedback is welcome.

 Also, do we really need option ignore? Isn't exclude option enough?

 Another suggestion is to use -f only for pattern option. When using names,
 it wouldn't require force flag for the actual removing of the maps. Any
 opinion on that?

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
--+-
 Reporter:  pvanbosgeo|   Owner:  grass-dev@…   
   
 Type:  enhancement   |  Status:  new   
   
 Priority:  normal|   Milestone:  7.1.0 
   
Component:  Default   | Version:  unspecified   
   
 Keywords:  g.list, g.remove, g.mlist, g.mremove  |Platform:  All   
   
  Cpu:  Unspecified   |  
--+-

Comment(by glynn):

 Replying to [comment:20 wenzeslaus]:

 > About "use fully-qualified names throughout" I though that it does not
 apply to the output

 No.

 You're only supposed to be able to create, remove, replace or modify maps
 in the current mapset. But that doesn't mean that you can't use a fully-
 qualified name, only that the @mapset part has to be the current mapset.

 Requiring the use of unqualified names in such cases imposes a burden on
 scripts, as they need to know that a map name refers to an output. When
 map names are obtained from the output of other modules, they may be
 provided as fully-qualified names, requiring the script to strip the
 mapset.

 Also, an unqualified name doesn't necessarily refer to a map in the
 current mapset. It refers to the first such map found in the mapset search
 path. At present, the current mapset is forcibly added to the head of the
 search path. This is a workaround for bugs in numerous modules and scripts
 which assume that this will always be the case, but it shouldn't be relied
 upon.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
--+-
 Reporter:  pvanbosgeo|   Owner:  grass-dev@…   
   
 Type:  enhancement   |  Status:  new   
   
 Priority:  normal|   Milestone:  7.1.0 
   
Component:  Default   | Version:  unspecified   
   
 Keywords:  g.list, g.remove, g.mlist, g.mremove  |Platform:  All   
   
  Cpu:  Unspecified   |  
--+-

Comment(by hcho):

 Replying to [comment:20 wenzeslaus]:
 > Replying to [comment:19 hcho]:
 > > Replying to [comment:18 glynn]:
 > > > Replying to [comment:17 annakrat]:
 > > >
 > > > > In the previous version of g.remove, full name was working. I like
 the previous behavior more but of course the mapset is not really needed.
 > > >
 > > > Even so, a fully-qualified name should be accepted provided that the
 mapset is the current mapset. Code which executes GRASS modules should be
 able to use fully-qualified names throughout.
 > >
 > > This behavior is now fixed in r62303.
 >
 > About "use fully-qualified names throughout" I though that it does not
 apply to the output (see also [http://lists.osgeo.org/pipermail/grass-
 dev/2014-September/070839.html mailing list], [http://osgeo-
 org.1560.x6.nabble.com/v-overlay-handles-mapname-mapset-in-a-wrong-way-
 td5162363.html nabble link]). When removing a map, it is of course
 questionable if we are executing our write access (as in case of output)
 or if we are using existing map (which we can specify with mapset).
 >

 I would say in this case, we're dealing with "input" or "existing" maps
 and g.remove should allow @MAPSET. IMO, names without @MAPSET only apply
 to "new" maps.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
--+-
 Reporter:  pvanbosgeo|   Owner:  grass-dev@…   
   
 Type:  enhancement   |  Status:  new   
   
 Priority:  normal|   Milestone:  7.1.0 
   
Component:  Default   | Version:  unspecified   
   
 Keywords:  g.list, g.remove, g.mlist, g.mremove  |Platform:  All   
   
  Cpu:  Unspecified   |  
--+-

Comment(by annakrat):

 Replying to [comment:19 hcho]:
 > This behavior is now fixed in r62303.

 Thanks. We are getting close to finishing g.remove/g.list interface. Does
 anyone has any opinion on the GUI layout? Related discussion:
 http://lists.osgeo.org/pipermail/grass-dev/2014-October/071179.html

 The problem of the current layout is that when you want to do the basic
 operation (removing one raster/vector map) you have go into 3 tabs
 (Required, Names, Optional).

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
--+-
 Reporter:  pvanbosgeo|   Owner:  grass-dev@…   
   
 Type:  enhancement   |  Status:  new   
   
 Priority:  normal|   Milestone:  7.1.0 
   
Component:  Default   | Version:  unspecified   
   
 Keywords:  g.list, g.remove, g.mlist, g.mremove  |Platform:  All   
   
  Cpu:  Unspecified   |  
--+-

Comment(by wenzeslaus):

 Replying to [comment:19 hcho]:
 > Replying to [comment:18 glynn]:
 > > Replying to [comment:17 annakrat]:
 > >
 > > > In the previous version of g.remove, full name was working. I like
 the previous behavior more but of course the mapset is not really needed.
 > >
 > > Even so, a fully-qualified name should be accepted provided that the
 mapset is the current mapset. Code which executes GRASS modules should be
 able to use fully-qualified names throughout.
 >
 > This behavior is now fixed in r62303.

 About "use fully-qualified names throughout" I though that it does not
 apply to the output (see also [http://lists.osgeo.org/pipermail/grass-
 dev/2014-September/070839.html mailing list], [http://osgeo-
 org.1560.x6.nabble.com/v-overlay-handles-mapname-mapset-in-a-wrong-way-
 td5162363.html nabble link]). When removing a map, it is of course
 questionable if we are executing our write access (as in case of output)
 or if we are using existing map (which we can specify with mapset).

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
--+-
 Reporter:  pvanbosgeo|   Owner:  grass-dev@…   
   
 Type:  enhancement   |  Status:  new   
   
 Priority:  normal|   Milestone:  7.1.0 
   
Component:  Default   | Version:  unspecified   
   
 Keywords:  g.list, g.remove, g.mlist, g.mremove  |Platform:  All   
   
  Cpu:  Unspecified   |  
--+-

Comment(by hcho):

 Replying to [comment:18 glynn]:
 > Replying to [comment:17 annakrat]:
 >
 > > In the previous version of g.remove, full name was working. I like the
 previous behavior more but of course the mapset is not really needed.
 >
 > Even so, a fully-qualified name should be accepted provided that the
 mapset is the current mapset. Code which executes GRASS modules should be
 able to use fully-qualified names throughout.

 This behavior is now fixed in r62303.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
--+-
 Reporter:  pvanbosgeo|   Owner:  grass-dev@…   
   
 Type:  enhancement   |  Status:  new   
   
 Priority:  normal|   Milestone:  7.1.0 
   
Component:  Default   | Version:  unspecified   
   
 Keywords:  g.list, g.remove, g.mlist, g.mremove  |Platform:  All   
   
  Cpu:  Unspecified   |  
--+-

Comment(by glynn):

 Replying to [comment:17 annakrat]:

 > In the previous version of g.remove, full name was working. I like the
 previous behavior more but of course the mapset is not really needed.

 Even so, a fully-qualified name should be accepted provided that the
 mapset is the current mapset. Code which executes GRASS modules should be
 able to use fully-qualified names throughout.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
--+-
 Reporter:  pvanbosgeo|   Owner:  grass-dev@…   
   
 Type:  enhancement   |  Status:  new   
   
 Priority:  normal|   Milestone:  7.1.0 
   
Component:  Default   | Version:  unspecified   
   
 Keywords:  g.list, g.remove, g.mlist, g.mremove  |Platform:  All   
   
  Cpu:  Unspecified   |  
--+-

Comment(by annakrat):

 I noticed that this:

 {{{
 g.remove type=rast names=test@user1
 }}}

 gives error:

 {{{
 WARNING: Illegal filename . Character <@> not allowed.
 ERROR: Illegal filenames not allowed in the names option.
 }}}

 In the previous version of g.remove, full name was working. I like the
 previous behavior more but of course the mapset is not really needed.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
--+-
 Reporter:  pvanbosgeo|   Owner:  grass-dev@…   
   
 Type:  enhancement   |  Status:  new   
   
 Priority:  normal|   Milestone:  7.1.0 
   
Component:  Default   | Version:  unspecified   
   
 Keywords:  g.list, g.remove, g.mlist, g.mremove  |Platform:  All   
   
  Cpu:  Unspecified   |  
--+-

Comment(by hcho):

 I just added names= and ignores= in r62244. These options take a list of
 filenames and convert it to a glob pattern.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
--+-
 Reporter:  pvanbosgeo|   Owner:  grass-dev@…   
   
 Type:  enhancement   |  Status:  new   
   
 Priority:  normal|   Milestone:  7.1.0 
   
Component:  Default   | Version:  unspecified   
   
 Keywords:  g.list, g.remove, g.mlist, g.mremove  |Platform:  All   
   
  Cpu:  Unspecified   |  
--+-

Comment(by hcho):

 Replying to [comment:14 wenzeslaus]:
 > Replying to [comment:13 glynn]:
 > > Replying to [comment:10 hcho]:
 > >
 > > > which can be misleading because it doesn't take multiple pattern
 strings, but it only takes multiple map names and a single pattern string.
 > >
 > > There seems to be two problems here.
 > >
 > > One is that the meaning of pattern=/exclude= may change depending upon
 whether -r/-e are used. I thought that we had already learned that making
 the semantics of one option change according to the value given for other
 options is a bad idea.
 > >
 > > The other is that there seems to be confusion over the meaning of
 pattern=/exclude= in the absence of -r/-e. Is it a list of map names, or a
 glob pattern? It can't be both unless both G_parser() and the GUI
 recognise "list of map names or string" as a distinct type. "list of map
 names" won't allow the use of glob patterns because G_parser() will
 complain about illegal characters and "string" won't work insofar as the
 GUI won't provide a browser interface for it.
 > >
 > I generally agree, I perhaps mentioned this several times. For the
 future, we need some higher level types. Some types are in "standard
 options" but they are not exposed. Another example of higher level types
 would be binary file and text file (as opposed to any file), GUI is now
 providing direct/interactive input box for binary files. With "color rules
 file" we can provide a GUI editor with preview besides the textual input.
 >
 > However, for this case, I think that the following is better option.
 >
 > > One solution would be to add a separate option (e.g. names=) which
 accepts multiple valid map names, mark pattern= and names= as mutually
 exclusive. names= would support multiple options and some form of
 browsing, pattern= would be a plain string. Similarly for exclusion.
 > >
 > This is quite simple and it also solves the problem I was afraid of:
 users seeing the option named pattern and not willing to use it because
 they want to input a map name not some pattern they don't understand.
 Option named `names` fits well with this use case. `maps` would be more
 consistent but it would not be precise and `names` goes well with
 `pattern`.

 I agree with you that this solution is better than the other because the
 main reason of replacing g.list/remove was to reduce redundancy. These two
 additional options would act as a wrapper around the pattern options.
 {{{names=}}} and {{{exclude_names=}}} should solve this issue in GUI. In
 command line, it's up to the user which one to use for a list of map names
 because the pattern options can handle a list of map names as well.


 >
 > > Another solution would be rename g.remove to e.g. g.mremove, remove
 the pretence about pattern=/exclude= being something other than "arbitrary
 string", and add a g.remove script which would be a thin wrapper around
 g.mremove (possibly the only difference would be to re-declare the types
 of the pattern=/exclude= options).
 >
 > This might go against the reasons for doing this whole thing, reducing
 the complexity of interface and maintenance cost by reducing the number of
 modules:
 >
 >  * http://osgeo-org.1560.x6.nabble.com/g-mlist-list-multiple-types-from-
 all-mapsets-td5142385.html
 >
 > Or were there some other reasons?

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
--+-
 Reporter:  pvanbosgeo|   Owner:  grass-dev@…   
   
 Type:  enhancement   |  Status:  new   
   
 Priority:  normal|   Milestone:  7.1.0 
   
Component:  Default   | Version:  unspecified   
   
 Keywords:  g.list, g.remove, g.mlist, g.mremove  |Platform:  All   
   
  Cpu:  Unspecified   |  
--+-
Changes (by wenzeslaus):

  * keywords:  g.remove => g.list, g.remove, g.mlist, g.mremove


Comment:

 Replying to [comment:13 glynn]:
 > Replying to [comment:10 hcho]:
 >
 > > which can be misleading because it doesn't take multiple pattern
 strings, but it only takes multiple map names and a single pattern string.
 >
 > There seems to be two problems here.
 >
 > One is that the meaning of pattern=/exclude= may change depending upon
 whether -r/-e are used. I thought that we had already learned that making
 the semantics of one option change according to the value given for other
 options is a bad idea.
 >
 > The other is that there seems to be confusion over the meaning of
 pattern=/exclude= in the absence of -r/-e. Is it a list of map names, or a
 glob pattern? It can't be both unless both G_parser() and the GUI
 recognise "list of map names or string" as a distinct type. "list of map
 names" won't allow the use of glob patterns because G_parser() will
 complain about illegal characters and "string" won't work insofar as the
 GUI won't provide a browser interface for it.
 >
 I generally agree, I perhaps mentioned this several times. For the future,
 we need some higher level types. Some types are in "standard options" but
 they are not exposed. Another example of higher level types would be
 binary file and text file (as opposed to any file), GUI is now providing
 direct/interactive input box for binary files. With "color rules file" we
 can provide a GUI editor with preview besides the textual input.

 However, for this case, I think that the following is better option.

 > One solution would be to add a separate option (e.g. names=) which
 accepts multiple valid map names, mark pattern= and names= as mutually
 exclusive. names= would support multiple options and some form of
 browsing, pattern= would be a plain string. Similarly for exclusion.
 >
 This is quite simple and it also solves the problem I was afraid of: users
 seeing the option named pattern and not willing to use it because they
 want to input a map name not some pattern they don't understand. Option
 named `names` fits well with this use case. `maps` would be more
 consistent but it would not be precise and `names` goes well with
 `pattern`.

 > Another solution would be rename g.remove to e.g. g.mremove, remove the
 pretence about pattern=/exclude= being something other than "arbitrary
 string", and add a g.remove script which would be a thin wrapper around
 g.mremove (possibly the only difference would be to re-declare the types
 of the pattern=/exclude= options).

 This might go against the reasons for doing this whole thing, reducing the
 complexity of interface and maintenance cost by reducing the number of
 modules:

  * http://osgeo-org.1560.x6.nabble.com/g-mlist-list-multiple-types-from-
 all-mapsets-td5142385.html

 Or were there some other reasons?

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
-+--
 Reporter:  pvanbosgeo   |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  7.1.0
Component:  Default  | Version:  unspecified  
 Keywords:  g.remove |Platform:  All  
  Cpu:  Unspecified  |  
-+--

Comment(by glynn):

 Replying to [comment:10 hcho]:

 > which can be misleading because it doesn't take multiple pattern
 strings, but it only takes multiple map names and a single pattern string.

 There seems to be two problems here.

 One is that the meaning of pattern=/exclude= may change depending upon
 whether -r/-e are used. I thought that we had already learned that making
 the semantics of one option change according to the value given for other
 options is a bad idea.

 The other is that there seems to be confusion over the meaning of
 pattern=/exclude= in the absence of -r/-e. Is it a list of map names, or a
 glob pattern? It can't be both unless both G_parser() and the GUI
 recognise "list of map names or string" as a distinct type. "list of map
 names" won't allow the use of glob patterns because G_parser() will
 complain about illegal characters and "string" won't work insofar as the
 GUI won't provide a browser interface for it.

 One solution would be to add a separate option (e.g. names=) which accepts
 multiple valid map names, mark pattern= and names= as mutually exclusive.
 names= would support multiple options and some form of browsing, pattern=
 would be a plain string. Similarly for exclusion.

 Another solution would be rename g.remove to e.g. g.mremove, remove the
 pretence about pattern=/exclude= being something other than "arbitrary
 string", and add a g.remove script which would be a thin wrapper around
 g.mremove (possibly the only difference would be to re-declare the types
 of the pattern=/exclude= options).

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
-+--
 Reporter:  pvanbosgeo   |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  7.1.0
Component:  Default  | Version:  unspecified  
 Keywords:  g.remove |Platform:  All  
  Cpu:  Unspecified  |  
-+--

Comment(by hcho):

 Replying to [comment:11 hcho]:
 > Replying to [comment:10 hcho]:
 > > Replying to [comment:9 annakrat]:
 > > > Replying to [comment:8 annakrat]:
 > > > > Replying to [comment:7 annakrat]:
 > > > > > Replying to [comment:6 hcho]:
 > > > > > > I just noticed two issues with the new g.list/remove GUI map
 selectors. They should not append @ mapset name and should support
 multiple selection.
 > > > > >
 > > > > > I fixed appending the mapset in r62220.
 > > > >
 > > > > Hm, it started to output warnings about illegal character *. Not
 sure what to do about that...
 > > > >
 > > >
 > > > I will probably have to revert this and do test for this specific
 case in the gui which I wanted to avoid. However, the problem with
 multiple selection is not just problem of the gui, but also pygrass can't
 currently handle it simply because g.list interface breaks rules.
 > >
 > > Hmm... One way would be to change the type of pattern=/exclude= to
 multiple and use their {{{answer}}} variable, not {{{answers}}}. The help
 message would be {{{pattern=string[,string,...]}}}, which can be
 misleading because it doesn't take multiple pattern strings, but it only
 takes multiple map names and a single pattern string. But, it works both
 in GUI and command line.
 >
 > If GUI allows for both multiple map selection and manual pattern typing.

 Still the {{{@MAPSET}}} problem needs to be fixed in GUI.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
-+--
 Reporter:  pvanbosgeo   |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  7.1.0
Component:  Default  | Version:  unspecified  
 Keywords:  g.remove |Platform:  All  
  Cpu:  Unspecified  |  
-+--

Comment(by hcho):

 Replying to [comment:10 hcho]:
 > Replying to [comment:9 annakrat]:
 > > Replying to [comment:8 annakrat]:
 > > > Replying to [comment:7 annakrat]:
 > > > > Replying to [comment:6 hcho]:
 > > > > > I just noticed two issues with the new g.list/remove GUI map
 selectors. They should not append @ mapset name and should support
 multiple selection.
 > > > >
 > > > > I fixed appending the mapset in r62220.
 > > >
 > > > Hm, it started to output warnings about illegal character *. Not
 sure what to do about that...
 > > >
 > >
 > > I will probably have to revert this and do test for this specific case
 in the gui which I wanted to avoid. However, the problem with multiple
 selection is not just problem of the gui, but also pygrass can't currently
 handle it simply because g.list interface breaks rules.
 >
 > Hmm... One way would be to change the type of pattern=/exclude= to
 multiple and use their {{{answer}}} variable, not {{{answers}}}. The help
 message would be {{{pattern=string[,string,...]}}}, which can be
 misleading because it doesn't take multiple pattern strings, but it only
 takes multiple map names and a single pattern string. But, it works both
 in GUI and command line.

 If GUI allows for both multiple map selection and manual pattern typing.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
-+--
 Reporter:  pvanbosgeo   |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  7.1.0
Component:  Default  | Version:  unspecified  
 Keywords:  g.remove |Platform:  All  
  Cpu:  Unspecified  |  
-+--

Comment(by hcho):

 Replying to [comment:9 annakrat]:
 > Replying to [comment:8 annakrat]:
 > > Replying to [comment:7 annakrat]:
 > > > Replying to [comment:6 hcho]:
 > > > > I just noticed two issues with the new g.list/remove GUI map
 selectors. They should not append @ mapset name and should support
 multiple selection.
 > > >
 > > > I fixed appending the mapset in r62220.
 > >
 > > Hm, it started to output warnings about illegal character *. Not sure
 what to do about that...
 > >
 >
 > I will probably have to revert this and do test for this specific case
 in the gui which I wanted to avoid. However, the problem with multiple
 selection is not just problem of the gui, but also pygrass can't currently
 handle it simply because g.list interface breaks rules.

 Hmm... One way would be to change the type of pattern=/exclude= to
 multiple and use their {{{answer}}} variable, not {{{answers}}}. The help
 message would be {{{pattern=string[,string,...]}}}, which can be
 misleading because it doesn't take multiple pattern strings, but it only
 takes multiple map names and a single pattern string. But, it works both
 in GUI and command line.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
-+--
 Reporter:  pvanbosgeo   |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  7.1.0
Component:  Default  | Version:  unspecified  
 Keywords:  g.remove |Platform:  All  
  Cpu:  Unspecified  |  
-+--

Comment(by annakrat):

 Replying to [comment:8 annakrat]:
 > Replying to [comment:7 annakrat]:
 > > Replying to [comment:6 hcho]:
 > > > I just noticed two issues with the new g.list/remove GUI map
 selectors. They should not append @ mapset name and should support
 multiple selection.
 > >
 > > I fixed appending the mapset in r62220.
 >
 > Hm, it started to output warnings about illegal character *. Not sure
 what to do about that...
 >

 I will probably have to revert this and do test for this specific case in
 the gui which I wanted to avoid. However, the problem with multiple
 selection is not just problem of the gui, but also pygrass can't currently
 handle it simply because g.list interface breaks rules.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
-+--
 Reporter:  pvanbosgeo   |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  7.1.0
Component:  Default  | Version:  unspecified  
 Keywords:  g.remove |Platform:  All  
  Cpu:  Unspecified  |  
-+--

Comment(by annakrat):

 Replying to [comment:7 annakrat]:
 > Replying to [comment:6 hcho]:
 > > I just noticed two issues with the new g.list/remove GUI map
 selectors. They should not append @ mapset name and should support
 multiple selection.
 >
 > I fixed appending the mapset in r62220.

 Hm, it started to output warnings about illegal character *. Not sure what
 to do about that...

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
-+--
 Reporter:  pvanbosgeo   |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  7.1.0
Component:  Default  | Version:  unspecified  
 Keywords:  g.remove |Platform:  All  
  Cpu:  Unspecified  |  
-+--

Comment(by annakrat):

 Replying to [comment:6 hcho]:
 > I just noticed two issues with the new g.list/remove GUI map selectors.
 They should not append @ mapset name and should support multiple
 selection.

 I fixed appending the mapset in r62220.

 If it is not in the interface of the module, gui can't know it should be
 multiple. As you wrote earlier, multiple pattern is handled by the module,
 which is the problem.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
-+--
 Reporter:  pvanbosgeo   |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  7.1.0
Component:  Default  | Version:  unspecified  
 Keywords:  g.remove |Platform:  All  
  Cpu:  Unspecified  |  
-+--

Comment(by hcho):

 I just noticed two issues with the new g.list/remove GUI map selectors.
 They should not append @ mapset name and should support multiple
 selection.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
-+--
 Reporter:  pvanbosgeo   |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  7.1.0
Component:  Default  | Version:  unspecified  
 Keywords:  g.remove |Platform:  All  
  Cpu:  Unspecified  |  
-+--

Comment(by annakrat):

 Replying to [comment:4 neteler]:
 > Replying to [comment:3 annakrat]:
 > > done in r62191, testing is welcome of course.
 >
 > There is a small issue now: clicking on "Map name exclusion pattern" in
 the GUI windows of g.remove now prints the word "element" into the
 terminal:

 Sorry, I forgot a print statement, removed in r62193.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
-+--
 Reporter:  pvanbosgeo   |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  7.1.0
Component:  Default  | Version:  unspecified  
 Keywords:  g.remove |Platform:  All  
  Cpu:  Unspecified  |  
-+--

Comment(by neteler):

 Replying to [comment:3 annakrat]:
 > done in r62191, testing is welcome of course.

 There is a small issue now: clicking on "Map name exclusion pattern" in
 the GUI windows of g.remove now prints the word "element" into the
 terminal:

 {{{
 GRASS 7.1.svn (nc_spm_08_grass7):~/software/grass71 > g.remove
 element
 element
 }}}

 (clicked twice in this test).

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
-+--
 Reporter:  pvanbosgeo   |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  7.1.0
Component:  Default  | Version:  unspecified  
 Keywords:  g.remove |Platform:  All  
  Cpu:  Unspecified  |  
-+--

Comment(by annakrat):

 Replying to [comment:2 hcho]:
 > I think that the current order makes it easier to implement a list of
 maps drop down. It's better to restrict map types first and then search
 for and list related maps in the drop down. Since we moved away from
 single option per map type, we may need some trick in the GUI.

 done in r62191, testing is welcome of course.

 The order - type, pattern - makes sense. I removed some unused types
 (#2440) so the pattern is now hopefully visible without scrolling. So we
 might perhaps close this ticket after testing and backporting.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
-+--
 Reporter:  pvanbosgeo   |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  7.1.0
Component:  Default  | Version:  unspecified  
 Keywords:  g.remove |Platform:  All  
  Cpu:  Unspecified  |  
-+--

Comment(by hcho):

 I think that the current order makes it easier to implement a list of maps
 drop down. It's better to restrict map types first and then search for and
 list related maps in the drop down. Since we moved away from single option
 per map type, we may need some trick in the GUI.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
-+--
 Reporter:  pvanbosgeo   |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  7.1.0
Component:  Default  | Version:  unspecified  
 Keywords:  g.remove |Platform:  All  
  Cpu:  Unspecified  |  
-+--

Comment(by annakrat):

 Yes, I am not satisfied either, I always overlook it and I go to the
 Pattern tab and use the exclude instead of the pattern option. So beside
 the change of order, we should also consider renaming the 'Pattern' tab to
 'Exclusion' perhaps? Or move exclude option to Optional? I personally
 don't use exclusion very often.

 Changing the order between type and pattern would mean that you would
 write:

 {{{
 g.remove "mymap_*" type=rast
 }}}
 instead of

 {{{
 g.remove rast pattern="mymap_*"
 }}}

 unless we do some special trick in the GUI which I would try to avoid.
 Would this change of the first parameter do any harm?

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #2437: order parameters in g.remove window

[GRASS GIS]

#2437: order parameters in g.remove window
-+--
 Reporter:  pvanbosgeo   |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  7.1.0
Component:  Default  | Version:  unspecified  
 Keywords:  g.remove |Platform:  All  
  Cpu:  Unspecified  |  
-+--
 On the 'required' tab of the g.remove function you first need to select
 the data type from a list. Below one need to type the map name search
 pattern.

 I have no clue if that is specific for my computer, but for the latter
 (the map name search pattern) I have to scroll down as the list of data
 types is longer then the height of the g.remove screen.

 I only ever need to select raster or vector (and I guess those are amongst
 the most used by the majority of users), so the scrolling to get to the
 bottom could be avoided by first being presented by the map name search
 pattern box and than the data type. For me that order makes more sense
 anyway, but that is just a personal preference.But having rsi problems,
 anything that could reduce the use of the mouse, however little, would be
 welcome (I know, I can use the command line more, and I try as much as
 possible).

-- 
Ticket URL: 
GRASS GIS 

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