kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 10/13/2017 2:51 AM, jp charras wrote:
> Le 13/10/2017 à 00:23, Wayne Stambaugh a écrit :
>> On 10/12/2017 1:52 PM, Kristoffer Ödmark wrote:
>>>
>>> On 10/12/2017 06:56 PM, Wayne Stambaugh wrote:
>>>> Kristoffer,
>>>>
>>>> There is no confusion and there is nothing to fix.  The document field
>>>> is just like any other field.  It is initially imported from the library
>>>> symbol to the schematic symbol (they are *not* the same nor should they
>>>> be) when a symbol is added to the schematic.  Once you modify a field in
>>>> a schematic symbol it takes precedence over the the field in the library
>>>> symbol that was linked when the symbol was added to the schematic.  It
>>>
>>> But it doesnt? If i set the variable Datasheet, which is mandatory, I do
>>> not get a context menu option to "Open documentation". I am not
>>> complaining about the document field, I am complaining that It is stored
>>> in two different ways, once in the dcm file and once in the library.
>>
>> I'm not sure why there is not an "Edit Datasheet" entry in the
>> "Properties" submenu of the symbol context menu.  I guess no one ever
>> noticed it before.  It probably would not be that difficult to add.  The
>> dcm file is for storing the description, key word, and datasheet URL
>> information for all library symbols.  The library symbol fields are
>> stored in the lib file and are only stored for the root symbol.  What
>> should happen is the alias document file text should be copied to the
>> schematic symbol DATASHEET field when it is added to the schematic.  If
>> it isn't, this is a bug.
> 
> FYI, in fact this confusion comes from a bug introduced a long time ago:
> 
> Initially, the field name was "Sheet" not "Datasheet".
> It should be "SchematicSheet"
> 
> The purpose was to be able to create a component acting as a hierarchical sheet:
> The component in a root sheet, and its internal sheet ("SchematicSheet") similar to a sub sheet.
> 
> But unfortunately, it was never done, and one day the word "Sheet" became "Datasheet", thus creating
> a serious confusion.
> 
> Perhaps the "DATASHEET" field (attached to the symbol) and the "documentation" string (attached to a
> alias) should be clearly redefined for the V5.
> 
> By the way, do you know why the .dcm file exists?
> It is similar to the .idx index file of old spice libs.
> 
> In the early time of eeschema, Kicad was stored on a server and was used in classrooms and on PCs
> connected by a "slow" network link: network cards were ISA cards and the link speed was roughly 2400
> bps.
> 
> So loading all needed schematic libraries to choose a symbol was a too time costly process, making
> Eeschema barely usable.
> Using small .dcm files to display a list of symbols and some info fixed this issue.
> 
> Nowadays, link speed, PC speed and memory sizes have 3 order of magnitude, and .dcm files (a relic
> of this time) is more an annoying feature.
> 

Thank you JP for the history lesson.  Even as long as I have been with
the project, I am always amazed how much I don't know about KiCad's history.

Cheers,

Wayne

>>
>>>
>>> Or are you saying that there is a difference between documentation and
>>> datasheet?
>>
>> Yes.  There is a mandatory (must exist but can be empty) DATASHEET field
>> for both the root library symbol and it's associated schematic symbol.
>> If you add a library symbol by it's alias, then the root DATASHEET field
>> would be incorrect so the "Document" (this is inconsistent but it's
>> legacy baggage which will be addressed by the new file formats) entry in
>> the dcm file would contain the appropriate datasheet link.
>>
>>>
>>>> has to be this way.  You would not want your schematic symbol fields
>>>> updated every time the library symbol fields are changed.  This only
>>>> makes sense for atomic (fully defined ) symbols and would completely
>>>> fall apart for generic symbols like op-amps and logic gates.  I believe
>>>> Orson recently added a tool to refresh the schematic symbol fields with
>>>> the linked library symbol fields.  I haven't tried it yet but you may
>>>> find that useful.
>>>>
>>>> Cheers,
>>>>
>>>> Wayne
>>>>
>>>> On 10/12/2017 9:12 AM, Kristoffer Ödmark wrote:
>>>>> Sorry for double messages but one solution could be to use the Library
>>>>> stored documentation to autofill the FIELD variable IF it is empty. And
>>>>> then base all the functionality on the field variable?
>>>>>
>>>>> I could probably fix this if it seems an okay solution to everyone? This
>>>>> would basically be making the field variable overriding the properties
>>>>> information. But still not break anything from the libs.
>>>>>
>>>>> Or should this just be left as is until the new symbool format is
>>>>> implemented?
>>>>>
>>>>> On 10/12/2017 03:00 PM, Kristoffer Ödmark wrote:
>>>>>> Hey!
>>>>>>
>>>>>> I noticed today that there are two places to store the datasheet
>>>>>> information, one is in the Mandatory Field "Datasheet", and one is in
>>>>>> the porperty of the part in the lib. These have different
>>>>>> functionality in the schematic editor and in the library part editor.
>>>>>>
>>>>>> I think these should somehow be merged or one of them removed. As it
>>>>>> is now, it is a bit confusing with the "Open Documentation" context
>>>>>> menu, and the "Show Datasheet" button in the properties editor.
>>>>>>
>>>>>> For me, mergin every functionality into the field variable seems like
>>>>>> the most robust way, since most other tools are using these field
>>>>>> variables and that is the most accesible way, and since the Datasheet
>>>>>> field is mandatory anyway, but can still be empty.
> 
> 
>