Mail Archives: geda-user/2015/04/02/12:17:10
On Apr 1, 2015, at 2:14 PM, DJ Delorie <dj AT delorie DOT com> wrote:
>
>> sqlite3?
>>
>> I have a bad habit of jumping to the implementation right away.
>
> I would prefer a text file, like CSV, but...
>
> The tricky part isn't the format, it's (1) choosing the right data to
> store, and (2) getting the data into the apps.
>
The trickier part is getting the operating model right. The idea that there can be a set of symbols suitable for everybody’s flow has always proven to be wrong. There are few symbols in *anybodys* library that work properly with *every* back end in *every* flow. Everybody who thinks there can be a standard design flow has a different idea of what it should be. That idea is driven by the particular kinds of projects they do, and the particular environment in which they do them.
The big $$ tools don’t get this “right" either. You are going to do a lot of symbol edits whether you want to or not.
Kai-Martin Knaak’s “essential” library on gedasymbols is actually pretty good. Don’t like it? See above. I predict that no committee will be able to do better.
The biggest problem we have is that the design of gschem is clumsy in this light. It would be much, much nicer if the symbol browser could import every symbol into a designated project symbol library. Embedding in the schematic files themselves, a commonly desired alternative, does not scale well. Projects would then be relatively immune to changes in the common symbol library (so it could be “repaired”, whatever that might mean). Symbols in a project library are easily edited or replaced as needed by the project.
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com
- Raw text -