kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 2/28/2017 9:29 AM, Maciej Sumiński wrote:
> On 02/28/2017 03:01 PM, Wayne Stambaugh wrote:
>> On 2/28/2017 4:37 AM, Maciej Sumiński wrote:
>>> Hi Wayne,
>>>
>>> Would you have a look at the attached patches? I do not want to
>>> introduce changes to the schematic plugins code without your approval.
>>>
>>> The first one removes multiple chunks of code that regenerate properties
>>> basing on the PART_LIB field values. Instead, a PROPERTIES object is
>>> maintained, so it is always ready whenever needed.
>>
>> This patch is fine.  I already had this on my list of updates after I
>> complete the symbol library table.  Feel free to commit it as it cleans
>> up the property creation code.
> 
> Ok, committed.
> 
>>> Regarding the second patch: I am looking for a way to store temporary
>>> changes to libraries. Libraries are linked to files, and now the binding
>>> is even stronger, as files are reloaded upon a change [1].
>>>
>>> It means that once I save only a part of modifications to a library, my
>>> buffer will be reloaded and the remaining unsaved changes will be gone.
>>> Do you think it is reasonable to disable cache updating when buffering
>>> is enabled?
>>
>> I not sure I understand your question but the cache reloading doesn't
>> make sense when copying libraries and creating the schematic cache
>> library.  Otherwise, you get a library file write every new symbol you
>> add to the library.  On a schematic with a 100 different symbols, this
>> would be 100 file write operations just to save a library cache file.
>> That is why I added buffering to the legacy I/O plugin.  I know it's an
>> ugly hack but it's a stop gap measure until the new file format is in
>> place which will eliminate the need for library caching.  I suppose we
>> could change the cache reloading but that could have it's own set of
>> issues.  Technically the cache should only be loaded when the cache
>> hasn't been created, the library file name changes, or the file time
>> stamp has changed since the last file load.  If the file is being
>> reloaded other than these cases, then there is a bug in the cache
>> loading logic.
> 
> Actually I wanted to limit cache reloading even more: do not reload the
> cache when a file timestamp changes & buffering is enabled.

That's fine but what happens if the file changes between the time it's
opened and the time it's changes are written?  Any changes made to the
file outside the current session are overwritten.  I know this is a rare
case but it is always a possibility.  I suppose we could assume the risk
and just overwrite any changes.

> 
> In the new library manager, I am creating copies of modified libraries.
> This way, one can select changes to be saved and drop the others.

You need to be careful here to make sure you refresh the schematic
symbol links when you update the copy of the library that contains the
schematic symbol links.

> 
> When a PART_LIB object is created, it is associated with a certain file.
> If there are two PART_LIBs associated with the same file and one of them
> has a new timestamp (i.e. editor saves *some* of the changes), the other
> object will reload everything from the saved file in cacheLib() method,
> losing all the unsaved changes.
> 
> I want to inhibit cache updating when buffering is enabled. With the
> proposed patch, it gets reloaded only if cache == NULL or if the file
> name changed, but not when the file contents is changed.

This seems like a reasonable approach to the problem.  Please try to
keep the library duplication code out of the plugin if possible.  I
don't want the plugin interface to get overly complicated.  I already
had to add code to the interface to support buffering which I would have
rather not done.

> 
> If you see an easier solution, I will be grateful for details.

I wish I did.  Unfortunately the transition from the legacy format
(linked symbols) to the new format (embedded symbols) is going to be an
ugly and painful transition.  It's going to be worse than what we went
through for the board file changes since footprints have always been
embedded in the board files.  I don't see any elegant way to get from
here the there bit I'm always open to suggestion.

> 
> Cheers,
> Orson
> 
>> Cheers,
>>
>> Wayne
>>
>>>
>>> Regards,
>>> Orson
>>>
>>> 1. https://git.launchpad.net/kicad/tree/eeschema/sch_legacy_plugin.cpp#n3359
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>> _______________________________________________
>> 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
>>
> 
> 
> 
> 
> _______________________________________________
> 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
>