[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gEDA-dev: some suggestions
> 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.
This is why I suggested it ought to be based on cleverly parsing the
system-rc files. They have comments about all options, so if done right,
the config editor can strip these comments, possible options to set, and
not need maintaining every time a new option gets added.
(So long as the appropriate comments and examples of the new option are
added in the system....rc files).
> Later, it could be integrated into the new project manager.
This doesn't exist yet. Peter B and myself wrote a GUI interface to
gsch2pcb, "xgsch2pcb" in Python + pyGTK. It is still alpha/beta, and
relies on DBus IPC features only just added to PCB in CVS. (Disabled by
default).
A full project manager was on the "TODO" list, but there wasn't time
when we were employed to contribute code. (And free time is less at the
moment!)
[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 ------------
Skimming the files myself, I think the existing comments - literally,
can be used. A little logic ought to be able to separate different
options and their appropriate text.
Your proposal is good for adding higher level groupings into the mix,
but we should be careful to specify what magic text triggers the config
parser to believe these are sections... is it the ";;" or the ";;
----" (dashes and all).
Anyway.. all food for thought as how you could potentially do a
config-editor which infered the options to edit from the config file its
self.
> 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'm not sure how useful this is. I don't think we can change the guile
parser.. isn't it a part of guile? I guess you are right though... a
config file editor would essentially have to be able to parse valid
scheme syntax. (And if comment information is to be read out, not
discard comments - as I expect many parsers might!)
I just wanted to suggest a possible way to make this less of a
maintenance nightmare.. if any one wants to implement a config editor,
feel free, any way you like!
Peter C.
_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev