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

[Glynn Clements]

Roger Miller wrote:

> > + save/load "view" created (list of layer, legend and extent)
> 
> 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.

> 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).

> Even better, could we give the monitor windows a default action in
> response to mouse clicks, double clicks, drags and so on?  I'd like it if
> the monitor came up with the functionality of d.where, d.zoom, d.erase or
> d.what.* already running and available with just a mouse action on the
> monitor.

This is going in the wrong direction, IMHO. The actual monitor
shouldn't do any of this. It should be a dumb "slave" to a GUI
program, which can then provide this sort of behaviour.

The mouse handling should probably go altogether. It doesn't fit into
the overall architecture (the GET_LOCATION_WITH_* opcodes are empty
stubs on everything other than XDRIVER), and the modal behaviour
doesn't sit well with the event-driven model used by GUI programs.

> I'd also like it if the active monitor were alway "on top" of the display
> and if it were possible to select a monitor (as with d.mon select=x*) with
> the mouse just by clicking it to give it the input focus.  That is, the
> "top" monitor is always selected, and the selected monitor is always "on
> top".  Again, this may be behavior specific to the window manager.  If so,
> then too bad.

Half of it is WM specific. The other half seems to be too heavily
based upon interactive use. E.g., if a script is composing an image on
the PNG driver, the selected monitor shouldn't suddenly change.

AFAICT, XDRIVER was never intended to comprise a GUI. Unfortunately,
enough interactive features have been tacked on at various points that
people are starting to mistake it for one. However, the less it
behaves like a dumb slave, the harder it will be to implement a real
GUI.

The only function which the monitors need to have in common with GRASS
is G_sock_get_fname(), so that GRASS and the monitors can
communicate[1]. Beyond that, while GRASS needs to know about the
monitors, the monitors really shouldn't need to know anything about
GRASS.

[1] However, the function should probably be provided by the monitor
subsystem and used by GRASS, rather than the other way around.

-- 
Glynn Clements <glynn.clements at virgin.net>