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.
>> 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.
>> 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 : [email protected]
>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>> More help : https://help.launchpad.net/ListHelp
>>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : [email protected]
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help : https://help.launchpad.net/ListHelp
>>>
>>
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : [email protected]
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help : https://help.launchpad.net/ListHelp
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : [email protected]
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
