kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 3/1/2017 4:38 AM, Maciej Sumiński wrote:
> On 02/28/2017 05:20 PM, Wayne Stambaugh wrote:
> [snip]
>>>>> 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 either case we lose data. What I would like to have is: if you enable
> buffering, then it means you do not care about the changes introduced in
> another session. It is simply a library copy to be modified. Otherwise
> every time the file is modified, the unsaved changes are gone from the
> editor, and it would be a frequent case.
> 
> If you prefer, I can use a new property that leaves the current
> principles as they are, and simply prevents reloading cache from disk.

It probably makes more sense to not reload the cache when the file
changes outside the current editing session so as not to surprise the
user loosing changes during the current editing session.

My preference is that all plugin specific options be implemented using
properties whenever possible.  This prevents features unique to the
plugin from changing the plugin I/O interface.

> 
>>> 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.
> 
> Good point. I assume using {Replace,Add,Remove}Part() is enough to
> achieve the goal as they modify the library hash. I will conduct more
> tests to be sure.

You still have to call SCH_SCREEN::CheckComponentsToPartsLinks() to
refresh the LIB_PART* inside the SCH_COMPONENT object after you make
changes to a library.  If you fail to do this, you may end up with a
broken LIB_PART*.

> 
>>> 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.
> 
> Sure, I do my best to reduce the number of changes to the current
> library/plugin interfaces. I am going to consult them with you before
> proceeding.
> 
>>> 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.
> 
> As with many refactors - there is some pain involved, but usually the
> end result is worth it.
> 
> Cheers,
> Orson
> 
>>> 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
>>>
>>
>> _______________________________________________
>> 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
>