[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: first impressions on gaf v1.2.0
Hi Peter,
Comments and thoughts are inserted in between (as rant-like as they came
up).
On Mon, 2007-10-08 at 08:19 +0100, Peter TB Brett wrote:
> On Sunday 07 October 2007 23:42:52 Kai-Martin Knaak wrote:
> > On Sat, 06 Oct 2007 21:45:56 +0100, Peter TB Brett wrote:
> > >> it fails to descend into subdirectories like almost any
> > >> file chooser does.
> > >
> > > The component chooser *is not* a file chooser.
> >
> > Still, the ability to browse the library in a hierarchical way would be a
> > major step ahead in usability. The long, linear list of library
> > directories is a pain to deal with. Most of the time I want to see only
> > my local libraries. But some times I want to browse the systems libs.
> > What is the problem with using the hierarchical features built into the
> > filesystem?
>
> I totally agree. I'm hoping to add "categories" to the component system
> soon(ish: there are several technical problems I need to overcome first).
>
> However, the first problem with depending on filesystem hierarchy for
> categorisation is as follows:
>
> 1. I have a system library which puts some symbols in
> the "IC/Regulators/Switch-Mode/National Semiconductor" category.
This (intricate) above level of symbols is very hard to maintain.
I suppose we do not want to divide TTL and CMOS ICs into subcategories
of subcategories of vendors ;-(
>
> 2. National Semiconductor bring out a new switch-mode regulator, which isn't
> in the system library yet, and I'm only a user and don't have access to
> change the system library.
I always have thought that /usr/share/gEDA/sym/local [could, should]
point to a (local) user directory, something like $HOME/gschem/sym and
[could, should] be used for this purpose (and other "local" purposes,
see below).
Sadly this directory is filled with symbols in the geda-symbols
tarball/rpm/package which probably should be filed in the "misc" (or
"other") category.
>
> 3. I therefore want to be able to insert a symbol from a totally
> different "component source" into the same category as the system library.
>
The database kind of solution of Levente Kovacs starts to appeal more
and more to me.
Combined with either local and/or web-based generic symbols and
footprints, as in:
- web-based and/or local database for parts references to generic
symbols and footprints (to be embedded in the schematic/layout file).
- local database for prices and vendor information.
- local database for footprint files and symbols with alterations based
on experiences of the user.
Web-based is thought by me in a "bazaar" like fashion as in
gedasymbols.org.
So a web-based "gedasymbols.org" symbol chooser is certainly on my Santa
wish list.
The web-based database has the advantage that one does not need to wait
for the next release.
A symbol/footprint is available the next minute after uploading.
This has become a bit better because of the high pace of releases that
came with the switch from cvs to git (let's see if the pace is kept this
high in a year or so).
OTOH, the stuff from the "bazaar" is as good and accurate as the author,
so let's remember who we lend the symbol/footprint from, so we can share
the praise/blame with them (scoring gEDA-points are we ?).
I mean validation of footprints/symbols has a binary nature in the
beginning, do we have smoke or no smoke ?
I think some kind of voting mechanism should be in place (as in
[experimental, stable, released]) for stuff from the "bazaar".
Whatever "experimental", "stable" and "released" come to have a
definition of.
> The second problem with depending on the the filesystem is that if I have a
> project-specific library, it's an awfully large amount of work to duplicate a
> (possibly enormous) category structure on disk just to add 5 symbols to
> categories deep within the category structure.
>
> How am I going to get around this?
>
No, it will always remain 5 categories deep ;-(
> - The category in which a symbol appears will be handled totally separately to
> the "source" which provided the symbol. You'll be able to view the library
> either by category (hierarchical) or by source (as currently).
>
> - There will be at least three different ways available for setting the
> category/ies for symbols from a given directory-based component source:
>
> 1. An index file.
> 2. All in the same category specified in the gafrc.
> 3. In categories according to the filesystem layout (I don't like this :P)
>
> I hope that makes this issues and proposed way of handling it clearer. Note
> that I have no idea about when this will be implemented!
>
> Peter
>
You may have noticed that I have some mixed (rant-like)
opinions/thoughts on the symbols/footprints issue.
I think that it is the primary responsibility of the users to create
"content", in principle the gEDA software should only provide a "method"
to use the "content".
BTW: It's up to the individual user if he/she wants to share his/her
symbols/footprints with a "bazaar"-like community.
OTOH, it would be nice to new users to give them a bit of a start with
common available parts that can be trusted (= released), to solve the
chicken-and-egg problem.
Possible candidates are (but not limited to): resistor, capacitor,
diode, inductor, switch and in the lightest possible way maybe an opamp
and a transistor (beware of the transistor/opamp problem). Not to heavy
to give an indigestion.
The geda-symbols tarballs goes far beyond the first needs of a new user,
and sometimes after several years a bug rears it's ugly head (see lm7912
voltage regulator discussion last month).
IMHO, the geda-symbols tarball needs to be validated and verified (that
is, re-assembled and yes, this will probably/possibly break stuff unless
we push the current symbols to gedasymbols.org, the current pcb
footprints are there already).
By "validated and verified" I mean: is this the right symbol and is the
symbol defined in a correct way.
To me, what we need most is a method to glue a symbol to the right
footprint (and/or other netlist parameters), so that means the focus for
improvements in gschem lays with the "attribute editor", not so much the
"symbol chooser".
The "symgen" symbol generator from Dan McMahill combined with the
database solution from Levente Kovacs could solve the
"transistor/opamp/logic-gate/other" problem. A.k.a. the "generic-part"
solution ;-)
As a side note, I think that now is the time to implement a consistent
way of naming footprints (for instance, the IPC naming convention
adapted with John Luciani's comments, John has some good points with the
IPC naming convention "standard").
And I think that the representation of, for instance, a resistor should
be based on some sort of a "locale" scheme (resistor-1.sym versus
resistor-2.sym, same goes for fuse, capacitor, npn and so on).
This has to do with user and local preferences.
This is similar to the "decimal point" issue some of us have (BTW: to me
and my fellow Dutch(wo)men it's a "decimal comma" issue).
And some of us earthlings write from right to left, lines from top to
bottom (Middle-east region), and some write from top to bottom, lines
from right to left (Japan), it's all solved in the locale.
I do not know how they do schematics ;-)
Just my EUR 0.02 (to me it is EUR 0,02 ;-)
Kind regards,
Bert Timmerman.
_______________________________________________
> geda-user mailing list
> geda-user@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user