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.
>
>>
>> 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.
--
Jean-Pierre CHARRAS
_______________________________________________
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
