Re: [GRASS-dev] [GRASS GIS] #1778: Typing in g.region without parameters does not open a g.region window

[GRASS GIS]

#1778: Typing in g.region without parameters does not open a g.region window
+---
 Reporter:  pvanbosgeo  |   Owner:  grass-dev@… 
 
 Type:  defect  |  Status:  new 
 
 Priority:  critical|   Milestone:  7.0.0   
 
Component:  Default | Version:  svn-trunk   
 
 Keywords:  g.region, r.colors, r.mask  |Platform:  Linux   
 
  Cpu:  x86-64  |  
+---

Comment(by glynn):

 Replying to [comment:15 cmbarton]:

 >  The problem you describe is indeed annoying. But it does not seem like
 a good idea to have modules behave inconsistently and unpredictably from
 the user perspective in order to solve it.

 The modules don't behave inconsistently. If you specify all of the
 required parameters, the module just does what it's told without further
 prompting.

-- 
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] #1778: Typing in g.region without parameters does not open a g.region window

[GRASS GIS]

#1778: Typing in g.region without parameters does not open a g.region window
+---
 Reporter:  pvanbosgeo  |   Owner:  grass-dev@… 
 
 Type:  defect  |  Status:  new 
 
 Priority:  critical|   Milestone:  7.0.0   
 
Component:  Default | Version:  svn-trunk   
 
 Keywords:  g.region, r.colors, r.mask  |Platform:  Linux   
 
  Cpu:  x86-64  |  
+---

Comment(by glynn):

 Replying to [comment:14 annakrat]:
 > So we need options to have another field (something like
 'group_required') which tells the parser that the certain options belong
 to a group of options where one of them has to be specified by the user.
 Would it be complicated to implement?

 The main complication is that someone will need to modify a very large
 number of modules to have them declare their requirements. If we're going
 to all that trouble, it would be better to finish the job.

 As well as the case where at least one of a group of options must be
 supplied, it's also common for certain options to be mutually exclusive,
 or for certain options to require other options. In all cases, there may
 be multiple such relationships.

 If the information on the relationships between options was supplied to
 the parser, not only could the parser perform such checks automatically,
 but it would be able to supply the information to the GUI. So the GUI
 could display this information to the user, e.g. by adding radio buttons
 to options which belong to an "exactly one of" group, and/or greying out
 options which have been excluded by the use of other options.

 To have the parser perform checking, it would be enough to specify the
 requirements as a boolean expression which must evaluate to true. But
 that's hard for the GUI to translate into visual cues, and it's also hard
 to produce useful error messages if the requirements aren't met.

 So we really need a more restrictive form, but still something which is
 flexible enough to handle the majority of the inter-dependencies between
 options. As to exactly what that form should be, we really need some input
 from the GUI developers.

-- 
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 7 tech-preview release preparations

[Glynn Clements]

Moritz Lennert wrote:

> On 26/08/13 23:24, Glynn Clements wrote:
> >
> > Moritz Lennert wrote:
> >
> >> - Two concern Windows code page issues (#995, #1288) for which I don't
> >> really know what a possible solution would be (is it possible to create
> >> a launcher for GRASS in Python, without using .bat at all ?)
> >
> > If the Python interpreter is registered, you should just be able to
> > execute the grass70.py script.
> 
> Do I understand correctly that for this to work the grass70.py script 
> would need to be altered to
> 
> - set GISBASE

It already does that if GISBASE isn't set.

lib/init/grass.py has a hard-coded fallback to @GISBASE@, which is
replaced with the actual value by the Makefile running it through sed. 
The installer would need to do something similar to substitute the
install path (or the grass.py script could read it from the registry
on Windows).

> - set the environment variables as defined in mswindows/env.bat

It already sets most of them if they're not already set.

> - set the CWD to %USERPROFILE%

That's optional. GRASS doesn't care what the current directory is.

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

Re: [GRASS-dev] [GRASS GIS] #1693: v.colors placeholder raster map naming option

[GRASS GIS]

#1693: v.colors placeholder raster map naming option
---+
 Reporter:  alf|   Owner:  hamish  
 Type:  enhancement|  Status:  assigned
 Priority:  normal |   Milestone:  6.4.4   
Component:  Shell Scripts  | Version:  svn-develbranch6
 Keywords:  v.colors   |Platform:  All 
  Cpu:  All|  
---+

Comment(by hamish):

 Hi,

 now backported to relbr64 with r57572.

 I'm not sure if/how this is handled in trunk after the v.colors rewrite to
 C, but as far as 6.x goes the wish can be considered closed.


 regards,
 Hamish

-- 
Ticket URL: 
GRASS GIS 

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