On 9/22/2010 9:58 AM, Dick Hollenbeck wrote: > > I'd like to emphasize: > > 1) the need to think this through now, right when we are contemplating a > new file format, and
Since I already have a preliminary component library file format document nearly complete, now would be a good time to get as much input up front as possible to prevent wasting time and effort doing things over. > > 2) we need to define terms early, so we can actually have a conversation > that can be understood. I suggest we use the term symbol to reference what we currently refer to as a component and use component to reference what we currently refer to as an alias. I think it more accurately describes the current file format and certainly anything I would propose for the new file format. I always felt the term alias was not very clear. To me 74LS00, 74HCT00, 7400, etc. are components. I've never used a 74HCT00 alias on a board before. I like the term symbol to represent how a component is drawn including pins, lines, arcs, etc. Until we agree on terminology, I suggest we continue to use the terms alias and component as they are currently defined to avoid confusion. > > > ------------- > > > My opinions, for a program like EESCHEMA in general: > > A) I don't find alias support to be particularly valuable, especially in > the presence of good library browsing capability. Doing away with the concept of aliases would certainly simplify the code for component library and component object. The current design of having multiple aliases referencing a single component makes adding them to and removing them from the library way more complicated than it should be. I also think it would be clearer to the user. > > B) EESCHEMA's library browser needs to be strong. > > C) Copying is not sharing. Sharing is when a single edit affects > multiple parts. There is not a significant value in "sharing" graphical > symbols between part specific components, particularly if it were > possible to simply copy a graphical symbol through the clipboard. If we implement proper copy and paste into the component library editor, supporting shared components becomes much less important. The down side is that it will make the file size larger. Given that the typical hard drive size for a laptop is 500MB I just don't see that as an issue. > > D) Project specific library support is important, and could be the > domain where symbols become part specific. > > > ---------- > > To me, 2) should be our highest priority, and it could almost read like > a few entries from a dictionary. I have a few: symbol - The graphical and/or electrical representation of a component. Think everything between DRAW/ENDDRAW in the current file format. field - The default and user defined text values that describe a component such as value, reference designator, footprint, etc. component - The combination of default and user defined fields and a symbol that get imported into a schematic. library - One or more components along with some meta-data to describe the library. Wayne > > > Dick > > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
