[GRASS5] sockets question

[Andrea Aime]

Strobe,
excuse my curiosity, but what programming language are you using, and
what kind of libraries? MVC is usually implemented using OO languages
(C++, Java and so on). There already are free GIS user interfaces, why
not try to reuse something already available? (take a look at
www.freegis.org)
Bye
Andrea Aime

strobe anarkhos wrote:
> 
> > >
> > > 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.
> 
> I'm only telling you the difficulty I have with supporting command line arguments. It's not a question of using fifos or not, it's a question of passing command line arguments to an already running process.
> 
> >
> > > >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.
> 
> Huh?
> 
> This has absolutely nothing to do with the GUI. when you construct a canvas of various maps and other elements it's not even visible until you display a view or print it.
> 
> When you create a canvas of maps and other display layers using the usual d.* commands you can either view or print it (or make a PDF of it).
> 
> The ps.* commands ought to drop off the face of the earth because they are superfluous. My method also works with any printer, whether it uses postscript, PDF, or raster. It's also easier to maintain.
> 
> >
> > > >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.
> 
> It's actually extremely easy to write a new UI for a set of commands. The difficult part would be writing a new set of commands using a new framework which I would like to do but probably won't.
> 
> Anyway the UI is the very last step in my project and will take the least amount of time.
> 
> >
> >
> > > 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...
> 
> Not really. The existing GRASS library would be the starting point, the commands would have to be re-written however.
> 
> My set of classes wouldn't be part of the base GRASS library but would use it. So long the new commands use my classes instead of the GRASS library directly everything would work.
> 
> >
> > > 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.
> 
> I tell you what, my "display driver" will implement things like persistence, multiple undo/redo, high-level scripting, and lots of interactive features. I can do this because the display commands do not alter the database model, only my internal graphics model, thus I have more control. If people want all commands (not just display commands) to have these features we can all get on the bandwagon.
> 
> If we were to pursue this any 'old' commands using the GRASS library directly would break the model, but new commands would not. That doesn't mean old commands wouldn't work, it would mean old commands would break things like undo and changes to the database wouldn't be reflected in the display in real time (they would have to be manually redisplayed).
> 
> ----------------------------------------
> If you want to unsubscribe from GRASS Development Team mailing list write to:
> minordomo at geog.uni-hannover.de with
> subject 'unsubscribe grass5'

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