[GRASS-dev] Re: r49205 - in grass/trunk: lib/python raster/r.info

[Michael Barton]

Shrug. Seemed like a good idea, but not a big deal one way or another as long as parsable out can be had. Still, consistency is desirable when wrapping command line code in a GUI in order to avoid custom coding each module. This is less important for typing to the command line.

Michael Barton
School of Human Evolution &Social Change
Center for Social Dynamics & Complexity
Arizona State University

...Sent from my iPad

On Nov 26, 2011, at 11:51 PM, "Hamish" <hamish_b at yahoo.com> wrote:

> Michael wrote:
>> Does this mean that we are abandoning the idea to
>> have -g determine *how* out put is printed (i.e.,
>> shell-script style) and use other flags to
>> determine *what* is printed? 
> 
> no/yes/in practice it doesn't matter &/or resolves
> itself with a natural solution so we are just
> arguing over irrelevant abstractions and bike shed
> colors at this point.
> 
> For one thing that was not ever actually decided.
> For g.region it was _attempted_ (amidst unresolved
> disagreement), and the result was a huge mess which
> took some months to recover from. But in the end
> and after all that pain it didn't really matter,
> as we were able to please both POVs because -g
> always implies -p. If someone wanted to think of it
> like -gp they could do that, if someone wanted to
> think of it as just a -g button to get a fixed
> result, they could do that too (most of the time).
> And we were all happy (AFAIK) and could move on to
> more productive and important things.
> 
> If you want to think about -g being coded to imply
> -p as the 'abandoning of the idea' of a strict and
> exclusive context switch, then yes we did abandon
> that shortly after the idea was first attempted
> some years ago. To me that is just a harmless
> compromise+convenience which doesn't break anything
> for anyone else.
> 
> 
> So now we have some modules (mainly r.univar) where
> -g acts to change the nature of the output, and
> most modules where you press that button you get a
> fixed response and can think of the "why" of it
> anyway you like.. Because typically you get the same
> output from both ways of thinking of it: you use -g
> when you want to get shell style output & it just
> works. I have a hard time imagining users ever
> being very confused by this minor distinction when
> they get what they want from either way of thinking
> about it. If you want to confuse users having a -g
> concept switch which outputs nothing when used
> alone seems like a great way to do it.
> 
> 
> Since I have never fully understood the "-g should
> be for shell script style only!" comments (because
> that has never changed), the best I can figure is
> that r.info and v.info's report-form output is being
> interpreted in others' eyes as the "-p" flag (which
> doesn't exist), and so the idea is that -g shows
> everything that the report-form shows, but in
> a more parsable format. Breaking that long list of
> report-form variables into 3 or so bite sized and
> conceptually grouped chunks just doesn't seem so
> horribly controversial to me. but maybe I miss the
> point.
> 
> 
> r.info and v.info basically remain almost identical
> in usage as they always have been. nothing much has
> changed except a bit of cleanup and consolidation.
> 
> 
> honestly this thing is such a non-issue and we have
> so many real bugs we could spend our finite energy
> and time on..
> 
> 
> through flexibility comes strength,
> Hamish