[GRASS-dev] r45050: v.info: -r/-m/-t -> shell param

[Benjamin Ducke]

I remember that we had a discussion a while ago on the
merits of making the GUI a separate project,
decoupled from the main GIS base.

Back then, the arguments where mostly centered on code
management and release cycles. I did not really want to
get into the discussion, as it felt a bit emotionalized.
But this sort of thing has me worried for some time.

I understand that in the starting phase of the new GUI
it was necessary to do some cleaning up of the CLI interfaces
so that the widgets would have a chance to 
interact properly with the modules. Fine; and it actually
did the old CLI interfaces a lot of good to undergo revision.

But for me, the point where we start modifying the CLI 
logics to improve the GUI appeal marks a dangerous threshold.
We should not get into a situation where we pit GUI
experience against CLI experience.

Thanks for listening. And please do not take this as
depreciative of the efforts of all those who are doing 
great work in putting together the new GUI.

Ben



----- Original Message -----
> Martin:
> > >> If so, why don't change some "standard" or "conventions" in
> > >> GRASS7? ;-)
> Hamish:
> > > because there's nothing really wrong with the old way?
> > > If there seem to many buttons in the GUI for a module,
> > > maybe the GUI module creation code should try for two columns
> > > or something? personally I am not too overwhelmed by the
> > > v.info and g.region 'Print' tabs, IMO they are fine and easy.
> >
> Martin:
> > well, the number of flags is the same as the number of
> > introduced options (shell parameter in v.info case), so
> > number of checkboxes in GUI dialogs is not changed.
> 
> so it has been made more logically complicated for exactly what
> gain then?
> 
> I find the "-x option does X, unless you have some modifier
> enabled, in which it does Y" a lot more confusing than "the -x
> flag does X, and the -y flag does Y". It is one less layer of
> abstraction to get your head around, which means easier to learn,
> debug, etc.
> 
> > They are just logically grouped.
> 
> they already should be, by the order they come in the code.
> just there is no visual breaks between groupings.
> 
> 
> but this gives me another idea on how we might find a solution..
> 
> so the problem you are trying to fix is not that the the user
> is presented with an overwhelming 747-cockpit's worth of options
> (such as d.vect can look like), but rather that within tabs it
> would help to group collections of similar options together?
> ?
> 
> if so perhaps we could implement a new thing in the module GUIs:
> thin 1 pixel wide light blue borders around groups of similar
> options/flags within a single tab.
> 
> this could either be with a new Option,Flag struct item like
> ->gui_group or ->gui_subsection, or perhaps it is cleaner and
> nicer to parse the existing opt->guisection like:
> _("section;subsection;subsubsection") if additional [;...] are
> present, the items get grouped.
> 
> if ->gui_group or ->gui_subsection was used any opts/flags
> within the same tab with the same group would be lumped together
> within a group box (optionally with small blue text in a gap in
> the top left border of the box with the group's name?).
> 
> I'm sure you can figure out what I mean as most gui widget kits
> support this & it is quite common, if not I can mock up a
> screenshot.
> 
> 
> > >> I remember discussion about number of flags of g.region.
> > >> There was suggestion to reduce number of flags as
> > >> I have done for v.info.
> > >
> > > it wasn't just discussion, it was committed and became a
> > > horrible mess for 2-3 months before it got partially
> > > reverted/cleaned up, and maybe now is still not as clean and
> > > clear as it once was.
> > > IIRC it was having a single -g flag which changed the behavior
> > > of all the other print flags. partly I'm trying to avoid that
> > > mess from happening again. a good idea perhaps, but it just
> > > didn't work in practice and made the entire GIS harder to use
> > > because it introduced a new paradigm.
> >
> > Probably time to make it better ;-)
> 
> as above, the modifier-flag way of doing it adds another layer of
> complication to learning the modules and in the code, which are
> both something I am not in favour of doing if we can help it.
> keep it simple.
> 
> 
> > Beside joking I would incline to keep -p/-g flag and
> > content control by the parameter.
> >
> > -p Print in human readable format
> > -g Print in shell script style
> >
> > Anyway there only few flags in g.region which could be
> > possible grouped into options of the new parameter (-e,-c,-3).
> >
> > print=basic,extent,center,3d
> >
> > What do you think about that?
> 
> as modifiers, or just to remove some flags?
> g.region is an extreme case and I'd have to eat something to get
> my blood sugar up before really being able to think about it
> clearly. :)
> 
> 
> > Speaking about v.info to add -g flag and content control by
> > print=basic,extent,topo [...]
> > Same can be done for r.info
> > print=range,resolution,type,region,units,datum,title
> >
> > r.info print=range,type
> > would print only range and type.
> >
> > r.info -g print=units,title
> > would print units and title in shell script style.
> >
> > ?
> 
> it's the same thing that was tried earlier for g.region. :-(
> also it means offering non-shell script style for everything
> which is current shell style only.
> is:
> max: 1.2345
> any clearer than
> max=1.2345 in the output window? Maybe a tiny bit but I'm not sure.
> 
> in general, as you may have guessed :) I don't like the modifier
> flag way of doing things at all.
> 
> 
> one thing it would depend upon (and would be useful anyway) is
> the ability to ctrl-click options in the GUI option pulldown menu
> allow multiple=yes in the GUI. Can that be done currently?
> still to do that is a trick which must be learned.
> easy to figure it out from experience, but experience !=
> intuition.
> 
> another argument against all this is that it forces English
> language onto something which was previously fully translated.
> sure there are other tool= options already which are locked in
> English, but we shouldn't make things any worse.
> 
> and finally, again, it's a major PITA for command script writers
> to have to type out the full textual description when the single
> letters already do the job in a very succinct way. we've got so
> many things that don't work properly, I'd love if we could focus
> on those instead of reinventing stuff which already does work
> well.
> 
> 
> best,
> Hamish
> 
> 
> ps- this reminds me of another issue which is not already solved
> in a good way ;) and would be useful: the idea of a DEG_FORMAT=
> {D|DM|DMS} g.gisenv variable to control if you get decimal
> degrees, DDD:MM.MMMMh, or DDD:MM:SS.SSSSh style output.
> presumably worked into G_format_northing() and G_format_easting()
> and friends.
> 
> 
> 
> 
> _______________________________________________ grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev


------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.