[GRASS5] sockets question

[strobe anarkhos]

>
>
> > My code uses functions in connect.c and SWITCHER.c in GRASS 5.0 to
> > check the validity of fifos and to then 'connect' to them (read/write
> > to them). The functions are used/copied verbatim, I don't change the
> > initial dispatch method (which is currently calling a bunch if inline
> > drawing functions). If your sockets implementation is similar to the
> > fifo implementation I should be able to support both methods easily.
>
>Pretty much all of the code in connect.c is usused/unnecessary with the
>sockets set-up (at least, I don't use it).  It is the source of some
>read() blockage that is one of the many places where a blocked read()
>call makes it impossible to handle Xevents like Expose.

I'll have to look at the new code I guess (sigh).

The old fifo code was really ugly. I mean connect.c shouldn't even exit, just put it in SWITHCER.c

Oh well I guess I'll have to somehow get a current source tree. I don't suppose anybody can tarball it, I can't use CVS easily because I'm on a modem, but I can download an archive from a faster ISP.

> > I hope nobody is adding functions to the display driver function set
> > in 5.1. As soon as I support the current set I'll post the functions I
> > plan to add for layers etc. Hopefully no parallel work is going on.
>
>I think we really need a function for plotting polygons with holes.
>I've been working on a major work-around in d.area, having now written
>some 1300 lines of code.  Modules should not have to go through such
>contortions...

The whole GRASS display system sucks IMO.

I don't want to fix an old system if we can move on to something better. For example after I add resolution independent display functions d.area would cease to use the old resolution dependent functions.

>
> > (FYI what I actually do is use two executables. One acts as the
> > display driver and tells the primary application which fifos to use to
> > create a new display canvas document. The display driver initializer
> > knows the primary app is running because it vends an object as a
> > server. I have to do this because fifos are passed as command
> > arguments instead of some runtime method which you may or may not be
> > using with sockets. Either way I can allow the primary application to
> > create or accept sockets or use the prior method if it's more like
> > fifos and command line arguments. I hope that made sense.)
>
>Are you saying, instead of having 2 programs involved, we'll now have
>three?

The problem is fifos are passed with a command argument and I do not want multiple display drivers running. Instead I have one app running which handles multiple sets of fifos. However to interface with the old command line syntax I need a seperate executable to act as the display driver which then notifies the primary app that a new pair of fifos are ready to be used.

I couldn't understand what you said about sockets so I'll have to look at the code somehow. It sounded like you still use command line arguments so I'll have to use the same technique. 

>
>In the long run, my personal opinion is we should move toward a regular
>GUI interface for interactive display usage.  Parallel to this should be
>an effort to expand and improve the capabilities of ps.map.  This way, in
>theory, we should be able to develop better interactive display tools,
>while having a good avenue for script-based generation of maps.  The
>CELL and PNGDrivers are serviceable, but it makes more sense to me to
>have a high level mapping language/command set and possibly have other
>targets than PostScript.

I disagree 100%

ps.* commands ought to drop off the face of the earth. I will support WYSIWYG printing, however I will not be using ps.* commands or any of it's code. I can do this because I'm using a higher level API which can convert resolution independent images to postscript, thus when d.area draws a map using my resolution independent commands my code constructs a vector map in floating coordinates which are implicitly composited to the screen, or a printer, or whatever. Thus I support superior postscript, PDF, and raster printing without much work.

>
>I know only enough GUI stuff to get me in trouble, but given the wide
>number of platforms we wish to support, I think Tk is the only viable
>solution.  I've seen some really nice Tk apps and I believe it could
>handle pretty much all we want.  


I disagree 100%

TclTk sucks. In fact there are serious limits to any graphical interface for commands. For example my specialized interface will support limitless undo/redo, but that will *never* happen with TclTk.

>
>The basic architechture of the display code is just wrong for
>interactive use.  It's just not designed to handle all kinds of random
>things that users do.  I don't have much experience here, but it seems
>the design needs to be more action-response oriented using callbacks or
>some other method.

It's not only the display code which is 'wrong' for interactive use (if I understand what you mean by that). The commands themselves are also part of the problem. 

If I could I would start over using the GRASS library as the starting point creating a framework for model, view, and control commands but I'm only one person and I have to work within my limits. As such I can work with the current flawed framework (time permitting).

My display driver will eventually support interactive features like limitless undo/redo, persistence, zooming, WYSIWYG printing, etc. However to create interactive features like group selection and so on we will have to create a new framework so that graphics can be treated as objects. It would be possible to use my work as a point to begin this framework, but I don't think I'll be doing it myself (unless I get paid or something).

In my experience it's difficult to get popular support for such things especially when they are used to crummy interfaces. 


---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'