From: Markus Neteler <neteler@geog.uni-hannover.de>
On Mon, Feb 19, 2001 at 09:34:22AM -0800, Eric G. Miller wrote:
> On Mon, Feb 19, 2001 at 04:15:06PM +0000, Markus Neteler wrote:
> > Hi all,
> >
> > the sockets driver is maturing quickly. Question is if
> > we should make it default for the forthcoming 5.0.0
> > or not.
> >
> > - we need a platform report about it's quality
> > o Linux: running well (better than fifos)
> > o SGI:
> > o Windows/Cygnus:
> > o FreeBSD:
> > o Solaris2.6/SUN: running well (better than fifos)
> > o Solaris8/SUN:
> > o Solaris/Intel:
>
> Yes, I'd like to hear a few more reports first. Does it work okay on
> CygWin? and every other target platform?
>
> > - what's missing (hi Eric)
> > - locks directory moved to $HOME/.grass5/ (?)
>
> Correct me if I'm wrong, but the global lock directory was only used for
> monitors under the fifo scheme?
Yes.> The sockets code doesn't use/need any
> such locks (drivers only handle one connection at a time -- all other
> connections wait or are refused; users no longer share a limited
> resource like fixed fifos).
O.k. But there was something with long path names and sockets:> However, I like the $HOME/.grass5/ directory for other reasons. There's
> already the G_home(), so it's only a little bit of work to set up
> element handling (e.g. subdirs). I want to make sure ~/.grass5 is chmod
> 4700 for a modicum of security. Is there a reason we might want it
> readable by processes not owned by the $USER?
I don't think so. $USER should be sufficient.> > - what's to be postponed to 5.1:
> > - scale in top line of monitor (?)
>
> In theory, this doesn't seem real hard (you already have put together
> some working code). However, there's the problem where the server
> process is never "informed" if a user changes region settings midstream.
> So, somewhere there'd have to be a mechanism for requery/update of the
> title bar.
Mhhh, what about d.zoom? Maybe it can talk to the XDRIVER?> > - auto-redraw when resizing (?)
>
> This seems to be more difficult, when you consider frames in addition to
> the window itself. The current code just deletes everything from the
> PAD list, clears the screen, and sets up a new pixmap buffer (if
> necessary). It would be nice to have, and seems like it should be
> doable. I think the resize code maybe needs to make a backup of the
> PAD, and then try to recreate the commands after the resize. I don't
> know?
Maybe this can be borrowed from d.zoom. Huidae may be able to tell us more
about it (tomorrow).
The similar code is in src/display/d.zoom/cmd/main.c and
src/display/d.zoom/cmd/redraw.c.
in src/display/d.zoom/cmd/main.c:
cmd = (char *)G_malloc(strlen(list[0])+1);
strcpy(cmd, list[0]);
for(i=1; i<nlists; i++)
{
cmd = (char *)G_realloc(cmd, strlen(cmd)+strlen(list[i])+2);
strcat(cmd, "\n");
strcat(cmd, list[i]);
}
make a backup of drawing commands.
in src/display/d.zoom/cmd/redraw.c:
system(cmd);
recreates erased maps.
Huidae Cho
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'