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" <[email protected]> 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 _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
