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 betteras 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,
Hamishps- this reminds me of another issue which is not already solved
in a good wayand 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@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.