On 03/06/2018 07:34 PM, Wayne Stambaugh wrote:
> Orson,
>
> On 3/6/2018 8:55 AM, Maciej Sumiński wrote:
>> I am trying to find a reasonable way to handle symbol and components
>> with invalid characters in their LIB_IDs (see bug report #1752419 [1]).
>> While now it is impossible to create such LIB_IDs, we need to handle
>> documents that had been created before the restriction was introduced.
>>
>> LIB_IDs in SCH_COMPONENTS will have illegal characters replaced on load,
>> but it is not the case for LIB_{PART,ALIAS} classes. Due to that:
>>
>> - Symbol-component links are broken (e.g. component with LIB_ID
>> 'Test/Name' will change to 'Test_Name', but the corresponding LIB_PART
>> will remain 'Test/Name'.
>>
>> - It is impossible to place/edit such symbols.
>>
>> The simplest solution is to process LIB_{PART,ALIAS} LIB_IDs in the same
>> way as id done for SCH_COMPONENTs, so they become valid names that match
>> SCH_COMPONENTs using them (see the attached patches). There are two
>> drawbacks:
>
> I would prefer to keep the behavior consistent with what is done with
> the SCH_COMPONENT LIB_ID renaming. I know it's less than elegant but we
> are going to just have to take our medicine until we transition over to
> the new file format.That is what I am thinking as well, so I have coded it this way in the patches. >> - Changing names that user had previously assigned, which might be >> annoying if LIB_IDs are used e.g. to create BOMs. Personally I would use >> the value field that accepts all characters for this purpose. > > Can LIB_IDs be used in BOMs? That would be an odd way to do it but I > suppose you could. Typically the contents of the value field is used > for BOM output not the symbol name. > >> >> - Naming conflicts may occur (e.g. both 'Test/Name' and 'Test:Name' will >> be changed to 'Test_Name', but I believe it is a rare case. > > I just used a simple counter to append digits to the end of the name in > the case of name conflicts in the remapping code so a similar approach > here would not be out of line. Good point, implemented and pushed to the master branch. Cheers, Orson >> Any thoughts? I believe a more elegant solution will be implemented once >> the new schematic file format is ready. > > The current behavior is just going to last during v5. Once the new > schematic file format is done and the LIB_ID parser and formatter > support escaping the / and : characters, we should be able to use any > character (except for control characters) in LIB_IDs. > >> >> Cheers, >> Orson >> >> 1. https://bugs.launchpad.net/kicad/+bug/1752419 >> >> >> >> _______________________________________________ >> 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 >> > > _______________________________________________ > 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 >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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
