[GRASS5] sockets question

[Eric G. Miller]

On Thu, Mar 15, 2001 at 01:06:33AM -0800, strobe anarkhos wrote:
> >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.

If you're going to do significant development work, it's worth getting
CVS going.  The initial download sucks, but updates usually aren't bad.
I only have a modem as well...

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

But why use fifos at all?  I guess I really don't understand what you're
shooting for.

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

Well, here I'll have to disagree 100%.  Interactive display needs are
not the same as generating cartographic products.  Additionally, if
you've ever had to generate 100 similar maps in a hurry you'll  find having
to use a GUI really sucks.  When you can script the whole thing, and go
home for the night -- now that's nice.

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

Well, I don't know what you intend to write, but rewriting an entire GUI
toolkit that's cross-platform is no small undertaking.

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

Yes, the architechture of the whole system is wrong...

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

Pretty much have to start from scratch I think...

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

Well, maybe as we get a better idea of what you have in mind, we can
have multiple people work on it...

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

Well, there is comfort in using what you already know.  But, I think
most people would warm nicely to a well-designed GUI for GRASS. 


-- 
Eric G. Miller <egm2 at jps.net>

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