Grass GUI (was Re: [GRASS5] Problems with vector import, and a suggestion)

[Roger Miller]

Glynn and all,,

I pointed out the various examples to remind folks that our exitings 
interfaces already provide a lot of these wished-for capabilities.  
Admittedly these aren't part of a refined GUI, but building a GUI isn't going 
to add those as new capabilities.  In fact I haven't really heard of that 
many capabilities that a better GUI would add.  I have to wonder how much 
effort one should expend on something that doesn't add capabilities. fix 
broken behavior or simplify repetiitve tasks.

You might get the impression that I'm not a big fan of GUI.  You would be 
right.  I have in the past added GUI to existing non-graphical programs, and 
developed others with GUIs that could have been built without them.  Usually  
the GUI takes up most of the programming time, and most of the final code is 
taken up by the GUI.  The actual function of the program tends to get burried 
in the cosmetics.  For non-commercial software it may be hard to see any 
value in all that effort.

> > d.save does the "save" part now, the "load" would be done by running the
> > script created by d.save.
>
> For a GUI, the format should probably be more amenable to editing than
> is the case for a shell script. Also, d.save doesn't allow for
> temporarily disabling commands; i.e. the command is still
> "remembered", but won't actually be run unless re-enabled.
>
> > > + view created usable in the map manager for output
> > > + query on the map (raster and vector) and (eventually with an
> > >   external function) manage the attribute of selected object(s)
> >
> > Of course we can query now (d.what.sites, d.what.rast, d.what.vect), but
> > it would be nice to be able to select objects and manage their attributes
> > interactively.
> >
> > > + mesure on the image
> >
> > d.area, d.measure.
>
> The modal interaction style of d.what.*, d.measure etc is more akin to
> the behaviour of pre-GUI programs than the event-driven model more
> common nowdays.
>
> It might be better if the programs which currently call
> R_get_location_with_{pointer,box,line} were redesigned so as to allow
> other programs to feed them coordinates.

Most of the user modules are simple enough that substantial changes can be 
made to them without huge efforts.  It seems like with relatively little 
effort many of them could be fit with whatever method you chose to drive them.

There are some pretty obvious exceptions:  the models like r.watershed and 
the very important and more complex capabilites provided by v.digit or 
r.mapcalc (for example) will not be easily changed.

> > From the command line--at least as of pre2--when the user creates a
> > monitor window, the focus is passed to the monitor (or is this just a
> > characteristic of the window manager?).
>
> Yes.
>
> Note that the monitor doesn't grab the "focus" in the strict sense
> (i.e. keyboard focus).
>
> > The monitor window is never
> > initialized in a state where it's ready to accept input.  That behavior
> > is annoying because it's always necessary to get the focus back to an
> > interactive shell before you can go on with whatever you are doing.
> >
> > Is there some way to keep a newly-created monitor from grabbing the
> > focus?
>
> Probably not in a portable manner. There may be tricks which will
> affect how individual WMs respond. Also, with some WMs, you can
> configure behaviour according to various window properties (e.g.
> title, resource name/class).

This is all really too bad.  I usually want a new window to come up in a 
state ready to take input.  I don't want to make a global change  in my WM 
behavior just to avoid annoyng behavior by GRASS.


Roger Miller