[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: gEDA-dev: some suggestions
Hi all,
A couple of years ago I felt the same urge, to create a geda-config GUI
based on Glade and some C callback code.
Since I learned that parsing is better done with any other language than
C, I gave up this urge.
IMHO, the way to do this right is to parse the system RC files for all
the configurable features that do exist (there may have been features
added since the previous release, as hinted by Stuart), and after this
parsing is done look for existing project RC files, and have the
features that have a meaningful value parsed.
Then it is time for the user to make up it's mind and change settings
(better is predefined in comboboxes or radiobuttons and whatelse, as not
to wander into unknown territory).
After the OK button is hit, geda-config can spew the new RC files after
the usual "OK to overwrite existing stuff" dialog etc.
Just my EUR 0.01
Kind regards,
Bert Timmerman.
-----Original Message-----
From: geda-dev-bounces@moria.seul.org
[mailto:geda-dev-bounces@moria.seul.org] On Behalf Of Stuart Brorson
Sent: Thursday, December 14, 2006 5:20 PM
To: gEDA developer mailing list
Subject: Re: gEDA-dev: some suggestions
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
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev