On Thu, 14 Dec 2006, Peter Clifton wrote:
On Thu, 2006-12-14 at 16:22 +0100, Christian Viller Hansen wrote:
Stuart Brorson wrote:
That's a good idea! A separate utility which gives the user a GUI
allowing him to configure a local gafrc would be a nice addition to
the project! My only thought is that it should dump the gafrc file
into the local director, instead of trying to overwrite the
system-gschemrc. All the stuff in system-gschemrc is overrideable
with the local RC file anyway, and you don't want to override the
system config file on a multi-user system.
It could be kinda like pspice where you can "add local" or add to your
general settings - but that's actually a recipe for disaster on a
multiuser system...
How about a "import settings from another project" button? The only
thing it needs to do is to give the user a directory selector and then
copy that gafrc to current project dir.
I think the utility should be reachable from within gschem. Is that a
problem?
I'd concentrate on how you want to edit the file / options first, then
worry about integrating with gschem. It could require architectural
changes to force it to re-read config options on the fly without adding
too many hacks.
Yeah, I agree. IMO, Christian should write a stand-alone GUI
configurator for gschem as a way to get his feet wet. The
configurator would just show a panel with a bunch of pull-downs,
buttons, and so on. It would read a gafrc file (or have a default one
built in), allow the user to modify it using the GUI, and then spit it
out into a desired directory using the usual file dialog.
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.
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.
Later, it could be integrated into the new project manager.
Another reason to leave it stand-alone is that then Christian (or his
successor) is responsible for supporting it and keeping it up to
date. That way there are no version skew problems within gschem
itself.
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.
On the other hand, provided files to have some structure to them:
[... snip....]
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.
Cheers,
Stuart
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
