On Monday 08 October 2007 21:33:38 Bert Timmerman wrote:
> 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 ;-(
It was an example of a possible category structure, not a foretelling of dire
fate. :P
> > 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).
Sorry, I've no idea what you mean. How the heck can a general, system symbol
directory point to a user-specific local directory? That's silly. If you
want a per-user symbol directory, specify it in your per-user gafrc -- it's e
exactly the purpose for which we have a per-user configuration file.
> 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.
We accept patches.
> > 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.
All of the above is entirely possible with the component library
infrastructure already in place (it's exactly what I had in mind when I
designed it). You can call an arbitrary external program or Scheme function
which provides a list of symbols & the individual symbols' content.
> 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.
I would very much like to move then entire existing symbols package to
gedasymbols in favour of a really minimal, lightweight symbol library to be
shipped with gEDA. The existing library can't decide what it's supposed to
be. Are the symbols supposed to be lightweight, or heavyweight? Are we
trying to include all likely devices used, or some definable subset? By
stripping back the -symbols package to a minimum, we can concentrate on
providing a good, solid basis for user's to build upon.
> > 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 ;-(
Why should it? Pessimist! :P
> [snip lots of sensible stuff]
>
> 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.
See my comments above.
Regards,
Peter
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ geda-user mailing list geda-user@xxxxxxxxxxxxxx http://www.seul.org/cgi-bin/mailman/listinfo/geda-user