Chris Cole wrote:
Jason wrote:
To me, The 'A' answer is to treat the gui like a scripted workflow.
All the CLI pieces underneath adhere to the Unix flexibility
philosophy, and a scripted UI/GUI joins it all together into your
particular workflow by calling each CLI program with the
appropriate options based on user input.
Well put. This is why I don't necessarily think it's a bad idea to
include gsch2pcb, or the ability to create a netlist, etc. in a GUI
tool. Maybe it's not particularly suited inside gschem, however and
the real tool that's missing is a gEDA IDE to help with the design
workflow? I haven't been particularly fond of IDE's in the past, but
that's mostly because they were software development IDE's and I
like to write code in Emacs :)
Wow, holy code-doesn't-die, batman!. This thread got me to thinking
about some old code I wrote. So I did some searching and found it.
dvd9to5 was a Perl script I wrote years ago for backing up my DVDs.
This was before dual-layer burnable discs.
You can find it here [1]. It's a good example of what I was trying to
describe. Although, please ignore coding style, comments,
capitalization, attitude, swearing, and the language Perl. I've learned
a lot (at least, what _not_ to do) since I wrote that. However, it's a
good example of wrapping individual CLI tools into one workflow to get a
job done.
thx,
Jason.
[1] - http://gentoo.osuosl.org/distfiles/dvd9to5-0.1.7.tar.bz2
_______________________________________________
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user