Mail Archives: geda-user/2015/04/01/22:53:14
On Wed, 1 Apr 2015, DJ Delorie wrote:
>
> In order to get the most participation, I set the least number of
> restrictions. It's a choice. If I had specified a rigid set of rules
> and formats, we'd have fewer symbols available to us.
>
> What we need is a way to index those symbols, and a way for gschem/pcb
> to read the indexes and use the files.
>
I agree.
I maintain my own set of symbols and footprints in my svn repository
(available for the public). I am sure there are other people doing the
same, outside of the centralized cvs. Trying to enforce some centralized
onely-one-good-way directory structure won't really work as a generic
solution: more people will start using their own repos.
I am against the database thing if it brings in new dependency for the
tools (e.g. sqlite). As an alternative it's okay as long as it's totally
decoupled, so there are external tools that handle the whatever database
engine and the tools keep on using files on the local file system. At the
end of the day, if an user doesn't want to use databases at all, there
should be no dependency or any sort of complication for that user. Same
generic preference goes for any sort of version control - keep it
external, don't hardwire your favorite VCS into any of the tools.
Bundling:
I have an idea for gschem for bundling symbols without messing with the
above consideration. There are embedded symbols already; we can embed and
unembed already. A library could be a schematics that simply embeds a set
of symbols. Most of the code is already there for this, and depending on
what we want to use it for there is only a little part to add. I see two
major use cases:
1. Use the bundle as a transport format: we only need a gschlas-like tool
that can pack symbols from files into an sch by name and can unpack such a
bundle into a set of directories/files in the current directory. This tool
is as external as CVS or SVN or an sql dump/import tool, so it's just an
alternative to pack up symbols. It's sort of a specialized tar (thus I am
not sure we really need it).
2. Support the bundle natively in gschem: the symbol library can contain
schematics that contain multiple symbols. In a sense such a bundle sch is
a leaf subdir in the directory hierarchy. This would be reflected in
the symbol selection dialog as well. While this would make
grabbing/sharing such bundles easier, I find this risky, tho: introduces
new corner cases, any indexing would required to understand and unpack
bundles, making modifications to a symbol in a bundle is harder, etc.
Since a PCB file embeds its footprints, the same boundling mechanism would
work there too.
Note: I had this idea during the previous discussion about how to clean up
the default library, and how to make it easier to download and add new
symbols into your local lib.
Regards,
Igor2
- Raw text -