Re: gEDA-dev: some suggestions

[Christian Viller Hansen <cvh-at-NOSPAMviller_dot_org>]

Stuart Brorson wrote:
> I don't think it's that hard, since it just has to write out a text
> file based upon a bunch of user selections.  Harder will be to
> maintain it, since the RC files are always changing as people add new
> features.

It could have a text area where all the stuff it doesn't understand can 
be dumped so the user hand-edit it there.

> I don't think it should be built into gschem, since -- as you say --
> that would require some architectural changes to gschem.  Anyway, the
> initial complaint involved not wanting to edit the RC files using
> emacs or vi.  A stand-alone GUI utility for lazy users seems like a
> good idea.  But I don't like the idea of incorporating it into gschem
> since it just adds complication and bloat.

Sounds reasonable.

> Later, it could be integrated into the new project manager.

What new project manager. Is it in cvs?

> Finally, I'm not going to tell anybody what to do, or what language to
> use.  Developers should do what makes sense for them.  But if it was
> me, I'd write it in Python, not in C.  It's basically a text-in,
> text-out program, and C is too low-level for that.

I was just about to suggest that. The reason I wrote C was in fear of 
having to write gui in scheme. Learning some scheme opened my mind to 
some abstract ideas behind programming, but scheme is not my friend! :(

Is python + gtk on the official geda road map? How about glade - go or 
no go?
I haven't done anything in python yet, but if it as easy as perl I'm 
sure I'll like it.

> Personally, I think one can do that in the existing files using
> judiciously placed comments.  That is, do this:
> 
> ;; -----------  Next section: foo variables  ------------
> 
> (set foo bar)
> 
> ;; ;; -----------  Next section: baz variables   ------------
> 
> 
> After all, the RC file is parsed and processed using
> guile.  Adding additional structure on top of the existing stuff means
> a more complicated guile parser.  The current one works quite well, so
> why make it more complicated (and prone to breakage)?  KISS is the
> by far the most important principle for modifications to gEDA IMHO.

I agree. Nothing should get more complicated. The options such a gui 
should be able to set are the most common ones and not all sorts of 
in-lined scheme code. If you have those requirements there is a good 
chance you'll also know how to write your own gafrc file. ;)


_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev