kicad-developers team mailing list archive

[Oliver Walters <oliver.henry.walters@xxxxxxxxx>]

Very interesting history JP! I think we are all looking forward to the new
library format :)

On 13 Oct 2017 17:51, "jp charras" <jp.charras@xxxxxxxxxx> 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.
>
> >
> >>
> >> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>