[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: gEDA-dev: footprint cleanup



I'll put in my two cents here.

I agree with Dan that modifying the M4 stuff so that it is installed
at build time is a better idea.  (Best done at "make dist" time, IMO.)
A single, unified footprint scheme is 
better for newbies since they aren't confronted with the obscure M4
stuff, leading to whines and complaints on the mailing list.

Since the M4 lib is the more extensive and developed of the
two, we don't want to just ditch its footprints.  Therefore, running
it at build time to create newlib-style footpirnts is the right way to
preserve the info held in it.   (Actually, I would run it at "make
dist" time so that only power users/developers would need ever deal
with footprint creation.)   No need to throw anything out.

As for Peter's point about M4's flexibility:  Sure.  But you can also
flexibly create footprints using Perl, Python, TCL, C, bash, or any
other language you choose outside of PCB.  Also, nothing will prevent
you from manually running M4 to create new footprints after the change
(right, Dan?)  Creating them on the fly
inside of PCB was a nify idea when PCB was written for the Amiga 20
years ago, but today it's non-standard, obscure, and poorly
documented.  All these attributes are bad for newbies.

Finally, another point about M4 is this:  How do you create new
footprints using M4?  What most people do these days to create a new
footprint is start with an existing footprint and then edit it (either
inside PCB or with emacs) to create a new one.  You can't do this
easily with an M4 macro, and since the generated footprints only live
in the .pcb file, the footprints it generates aren't useful for
cloning another footprint without jumping through a lot of hoops (at
least from teh new user perspective.)

As Peter says, "the way the PCB footprint libraries work at the moment
are really pretty impenetrable and user-unfriendly."  Indeed.  To
properly fix, upgrade, and document them enough to make them
transparent and newbie-friendly would require a lot of work, and would
ultimately still present two radically different footprint paradigms
to the user (M4 and newlib).  Since a lot of work must be invested to
create a confusing system, it doesn't make sense to do it at all.

Finally, remember the principle of economy which must be bourne in
mind when thinking about successful open-source projects:
Programs should be simple enough so that they can be maintained by
part-time volunteers, and user-friendly enough that they can be
understood by newbies without a lot of support and documentation.
I don't think the M4 system meets either of those two critera, and may
never meet those criteria even after a lot of work.

JMHO,

Stuart



On Tue, 29 Aug 2006, Timmerman, Bert wrote:

> Hi Igor2 and Dan,
>
> I agree, if it's not clear or suitable, the average user/newbie would
> start with the creation of a newlib footprint.
>
> I once looked at an m4 file and decided it was not for me.
>
> A footprint generator that can be invoked with pcb would also be handy
> (some kind of gui hid module/wrapper around m4).
>
> So the choice would be:
>
> - Select an existing [newlib, oldlib] footprint sorted in lists by
> component or package type with Least, Nominal or Most material
> conditions (and not by creation method).
>
> or
>
> - Create a footprint in the newlib style and add it to the layout file.
>
> Wether the internals are using m4 is to no interest for the average user
> (power users are left on their own milage, they should be wise enough
> ;-).
>
> Just my EUR 0.01
>
> Kind regards,
>
> Bert Timmerman.
>
> BTW, on a higher level (pcb file): another problem in footprint
> cleanup/creation and audition/correction lies in the fact that once
> embedded footprints (as in older designs) are never updated when a bug
> is corrected in a footprint.
>
> This is in contrast with gschem, where one has to embed a symbol on
> purpose (explicit), and a modified (not embedded) symbol will be loaded
> with the schematic.
>
> Wether this is a bug or a feature of pcb is not for me to decide.
>
>
> -----Original Message-----
> From: geda-dev-bounces@moria.seul.org
> [mailto:geda-dev-bounces@moria.seul.org] On Behalf Of Igor2
> Sent: Tuesday, August 29, 2006 11:44 AM
> To: gEDA developer mailing list
> Subject: Re: gEDA-dev: footprint cleanup
>
> On Tue, 29 Aug 2006, Peter TB Brett wrote:
>
> <snip>
>
>> I agree that the way the PCB footprint libraries work at the moment are
> really
>> pretty impenetrable and user-unfriendly.  But *please* don't throw the
> baby
>> out with the bathwater!
>>
>> Peter
>
> I agree. I think a beginner won't care whether it's m4 or not, the
> difference in the selector window is not that clear. And if he doesn't
> know, why would he care?
>
> I also like the idea that we don't have 10000 megabytes of footprint
> files
> which differ only in 2 bits from one another. Maybe because I don't have
> 160 GB disks :)
>
> Maybe the best would be to have a HID or other _simple_ C api to
> separate
> the footprint loading and have the newlib and the m4 code in different
> directories, like the HIDs in hid/. This also would allow one to expand
> the footprint side easier (databases and whatevers).
>
> Regards,
>
> Igor2
>
>
>
> _______________________________________________
> 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
>


_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev