kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 09/21/2010 05:28 PM, Karl Schmidt wrote:
> One of the ultra cool features in kicad is the ability to right click to a schematic symbols PDF 
> files.  I'm running into a situation that has me thinking it could be even better.
>
> Sometimes I have parts with multiple manufactures - and I want both data sheets associated with the 
> part. I've been working around this by running pdfjoin ( Part of the pdfjam package ).
>
> I'm thinking it would be better if a part could have more than one datasheet pointer in eeschema 
> where the DocFileName field could hold more than one file name. Then right clicking would bring up 
> more than one docfile.
>
> Another way of dealing with this situation would be to use an editable doc file type that could 
> ingest PDFs.
>
> How do others deal with this?
>   


I was recently reminded that the library components are not necessarily
"part specific".  Many are in essence *symbols* not parts, and we might
do better to refer to them as symbols rather than as parts.  It is only
after they are instantiated into a drawing and assigned a "value" that
they truly become representative of an actual real world part, i.e. part
specific.  Granted, it is currently possible to design a symbol to be
part specific out of the get go.  But on the other hand, look at a
resistor symbol, it is multi-purposed in the library and only becomes
part specific when obtaining a value in the instantiation.  So we have
two categories of "library components" (which I'd argue are better
referred to as symbols, at least with the current EESCHEMA design).


Assigning a DocFileName attribute to a *symbol* makes no sense for pure
symbols, even to hold a single document name, let alone multiple names. 
This is surely true for the resistor symbols, and less true for part
specific library components.

It has been said on this list that the DocFileName is redundant with the
"DATASHEET" field.

Another idea to put on the table for consideration is to:

** remove DocFileName altogether in favor of moving this information
into the "fields" (aka properties), starting with fieldname "DATASHEET",
and continuing with additional fields.  In support of the PDF viewing
capability, we could add some mechanism to treat any field as a viewable
document in the user interface.  Candidate mechanisms might be a right
click popup menu choice, or a field "type" column or checkbox, and more
(this is not a complete list for brainstorming purposes).


We also have to consider the fact that the fields/properties in the
instantiation can be different from fields/properties in the associated
library symbol.

I will continue on a separate thread called "library structure".


Dick