gEDA-user: Free Dog meeting report: Notes on the topics we discussed

[sdb@xxxxxxxxxx (Stuart Brorson)]

Herewith, the notes Ales and I wrote up after the Free Dog meeting of    
Wed. 9.14.2005.  I am posting them because many geda-users have
expressed an interest in seeing what we discuss at these meetings.  I
don't claim that these notes are complete or objective, so feel free
to comment on what I report here! 

  -- Stuart

---------------------  Free Dog notes  --------------------------
Four people turned out for our Free Dog meeting tonight:  me (Stuart),
Ales Hvezda, John Luciani, and our guest from out-of-town (and
frequent geda-user contributor), Bob Paddock.  Here's, a quick list
of topics dicussed (or at least those which Ales and I remembered),
and commentary on the topics: 


* The current geda.seul.org download page ideas and comments.
Particular question:  Is it too complicated?

I thought the current page was OK.  However, after some discussion in
the group, placing explicit instructions about what to download and 
what to do on the downloads page was thought to be a good idea.  (The
info is currently hidden in several READMEs linked on the "downloads"
page.)  The issue raised by Karel is that we have lots of total
newbies trying to use the software, and Eagle makes their lives much
too easy, at least when it comes to download and installation.  Does
somebody have some text they would prefer to see on the download page?
Contributed text would allow Ales the chance to simply cut and paste
to the page . . . .   


* Symbol library organization approaches: advantages and
disadvantages.  

We discussed the ongoing discussion on geda-user about the symbol
libarary.  I continue to think that a Google-type search engine makes
sense; a search engine makes discussions about how to organize the
libraries moot, since you can then find the component you are looking
for by a simple string search.  Ales  thought that was a nice idea.
However, the devil is in the details: For most parts, the only
description of the part is in the symbol name (e.g. MAX232-1.sym).
Therefore, implementing a string search means that we need to populate
the "description" (or "keyword" or "tag") attribute in each symbol.
Then, the string search (e.g. grep) would first locate this attribute,
and then grep through it looking for the "searched-for" attributes.
I personally think that this scheme would augment any library naming
scheme nicely, and would help those folks who complain that they can't
find a symbol.  However, almost no symbol has the description
attribute filled out right now.  It also raises the old issue of light
vs. heavy symbols.

There are other approaches to the symbol libarary:  For example, John
opts for a better naming scheme for the libraries.  His scheme would
incoporate information about both the class of the component, as well
as (sometimes) its manufacturer.  For example:  

connector-header .................. dual and single row headers
connector-misc .................... battery holder, DSUB, jumper, ...
connector-power ................... power connectors
ic-Chipcon ........................ ICs from Chipcon
ic-Cirrus-Logic ................... ICs from Cirrus-Logic
ic-linear ......................... linear components op-amps, comparator, etc.

He sent a complete overview of his scheme to the participants.  Ales
averred that he liked the scheme.  Since Ales is also planning to
revamp the symbol libraries, you might expect to see John's scheme
implemented in the next gEDA/gaf rev. 

Also, our current scheme is 2 layers of hierarchy: library names on
top, then symbol files.  One suggestion raised (by me) was: we could
adopt an N-layer hierarchical scheme, something like the dos/unix file
system. (N is an aribtrary number.)  Then library names (like folders)
could intermingle with symbol files at any desired layer of
hierarchy.  However, this idea was shot down as too complex, and
requiring too much work, and I agree that it is too complicated.  It
also doesn't solve the original problem: Users can't find the symbols
they want.  


* Ideas for improvements/ideas for the parts browser.

Ales wants to make this use the generic file browser widget present in
GTK.  I like it the way it is, as long as the "preview" box is enabled
by default.  Ales modified the master gEDA copy per my desires.  Thank
you, Ales!  As for replacing the current parts browser, Ales is still
interested in doing this. 


* Light vs heavy symbols briefly discussed again

This discussion grew out of the discussion of how to handle finding
symbols.  If you put too many searchable component attributes into a
symbol, then it becomes heavy, and can become a maintainence
headache.  Bob recalled from his experience in manufacturing that any
small change in the component's properties (e.g. manufacturer change,
etc) could lead to a cascade of changes and ECOs throughout the
manufacturing  system.  We don't necessarily want that for the symbol
libraries. 


* Linux binaries of the gEDA suite

Ales said that he has now seen at least one successful example of how
to distribute compatible binaries of a complex GTK+ applications.
Therefore, we agreed that it would be a good idea to
include gEDA binaries on the installer, but the binaries
will be dozens of meagbytes large.  I will (eventually) modify the
installer to ask the user whether he wants to install from source, or
install (large) binaries.


* The Windows port and its current lack of state

Ales showed off the latest gschem working under MinGW.   Everbody was
impressed.  We discussed whether PCB worked fully, natively under
Windoze (not under Cygwin, but possibly under MinGW).  I avered that
somebody on geda-user had reported a successful compilation/execution,
but I forgot the details. Does anybody on this list want to report
success running the GTK version of PCB (gPCB) on Windoze?  And if
you've gotten it working, what hacks did you implement to make it
work? 

Additionally, Ales said that the Windoze port of gEDA/gaf was wildly
popular, even though it was several years old.  Bob said that his boss
wanted a Windoze port.  I, again, opined that Windoze users could
perform unnatural acts on themselves.  Due to its evident popularity,
Ales suggested that he would work on the Windoze part.  I suggested
that he could recruit somebody else to do the work.  Are there any
Windoze developers on this list who want to try porting/compiling the
latest gEDA/gaf to Windoze?


* Various approaches people take when going from schematic -> BOM with
  part numbers

Me (Stuart):  gattrib & gnumeric.  I draw my schematics with gschem, then
annotate things like footprints and part nos with gattrib.  Since
gattrib now can add new attributes (i.e. add new columns), I can use
it to include arbitrary information into my schematic.  When my
design is frozen, I do "gnetlist -g bom2", and then import the text
file into gnumeric and finalize the BOM there.

John:   John has written lots of incredibly clever Perl scripts to
process his design.  I'll let him describe his design flow in detail.
Here, I will simply observe that his Perl scripts will take his .sch
file, and for each component will key off the component's attributes,
do a search on a parts database which he has created, and then
backanno info from the database (such as vendor and vendor part no )
into the .sch file.  From this John can create a BOM ready to be
ordered.  It's simply incredible!

Bob:  Had his own C++ program which handled BOM creation.  He also
mentioned that he had gotten Compire -- the ERP system -- up and
going, but wasn't using it yet. He said that due to his background in
manufacturing, he was interested in using Compire to create an entire
open-source design and manufacture flow. 


* Backannotation from PCB to gschem. 

This is a topic of frequent discussion.  Last night's idea was to do
backanno in two steps:  The first step (using "geco" program) would
create a cleartext .eco file from a changed .pcb file.  The .eco file
would then be used (by "gbackanno") to update the .sch file.  The
advantage here is that you would have a record of changes made in the
.eco file, and you could edit the .eco file with emacs (or whatever)
before doing any backannotation into gschem.

Here's the full proposed design cycle (in ASCII art):

    +------ (.sch) ---->  gnetlist  ------ (.pcb.new) ------+
    |                    (gsch2pcb)                         |
    |                                                       |
    |                                                       V
  gschem                                                   pcb
    ^                                                       |
    |                                                       |
  (.sch)                                                  (.pcb)
    |                                                       |
    +--------  gbackanno <----- (.eco) -----  geco <------ -+ 



* Discussion of Dan McMahill's issue raised in his last e-mail:  He
wants to embed the library name into the schematic along with the
symbol name.  For example:  analog/resistor-1.sym instead of
resistor-1.sym. 

This idea was discussed, but nobody understood what problem it
solved, besides designer laziness in giving two symbols the same name.
Personally (please flame me if I am wrong), I thought it would break
too many old schematics to fix a minor problem.  Dan, please forgive
our (possible) stupidity, but what problem is being fixed by this
suggestion?  And is the problem large or small?  


*  We discussed Paul Bunyk's proposal that a single button be pressed to
netlist a schematic (for example).  This is part of a larger desire to
have a more integrated package for gEDA/gaf (i.e. netlist from within
gschem).

The problem with this is that gschem does not have the concept of a
multi-sheet design.  Therefore, if you press a "netlist" button in
gschem, which sheet is netlisted?  Only the current one?  Or all
opened sheets?  What if you have a six sheet design, but only two of
the sheets are open?

We agreed that the project manger "geda" would be better poised to do
this kind of task, since it *does* have the concept of a design, and a
project, as well as that of a single schematic sheet.   Anyway, an
integrated design suite should have a top-level program like "geda"
whcih is used for tasks like taking a schematic to a netlist.  (This
is currently best done at the command line.)  The problem with "geda"
is that it is buggy (at least in my experience, if not in others), and
hasn't been maintained for several years.  Perhaps somebody would like
to take ownership of the "geda" project manager? 


* Post meeting - use of Wiki in the gEDA webpage.

Ales suggested using a Wiki to hold information about gEDA.  In
particular, he wants to use something like a Wiki to hold a FAQ, and
direct newbies with questions to the FAQ, where currently he has to
monitor the mailing list, or answer via e-mail.  I think this is a
great idea.

THe problem is spam, and how to control/prohibit spammers from writing
garbage to the gEDA Wiki?

I suggested:  Use a Wiki allowing different write permissions on
different pages.  Then, a subset of pages will allow only Ales to
write them (e.g. the basic documentation), and the other pages will be
writable by a set of users who must first get permissions set by
e-mailing Ales.

An alternative is to allow free writing for the writable pages by
everybody, but have the gEDA-cvs mailing list mail out a notice
everybody with CVS access.  Then one of the CVS-level people could
check the latest Wiki entry.  


* Post meeting - QCad and the next meeting

QCad was discussed, and we hope to try out BRL-CAD at the next Free
Dog meeting, to be held at the normal time in Cambridge, MA.


Please feel free to comment/dispute any of the observations I include
here.  The topics are meant to stimulate open discussion!

Stuart

-------------------------------------------------------------------