| Thread Previous • Date Previous • Date Next • Thread Next |
Wayne Stambaugh wrote:
Dick Hollenbeck wrote:Wayne Stambaugh wrote:I thought I remembered a discussion about removing the dcm files, or putting that info into the other file.Mateusz wrote:Could you tell me how this "tags" will be\are implemented in .lib files? Do you need a special tool to add key words, or can it be done via library editor?When the component library editor saves a component library, two files are created. The .lib file contains the information about how to draw the components, default field values, aliases, etc. The .dcm file contains documentation for each component and component aliases for a library.Am I imagining this discussion? I honestly cannot remember for sure, but I thought Jean-Pierre was OK with removing the dcm files. I think long term having to marry two files together may eventually get in our way and be cumbersome.Dick, These are separate discussions. I discussed merging the two files as part of the ongoing improvements to the component library object. I have been slowly adding the base code required to accomplish this in an unobtrusive manor as possible. When I discussed this with JP, there was no talk about the library improvements currently being discussed. I am perfectly fine with not merging them if the proposed library clean ups will make the .lib file too unwieldy. Currently the .dcm files really don't have much information in them. If the folks working on the library improvements add a lot of additional documentation to the .dcm files then your concerns may be valid. I was thinking primarily from a developer point of view of have to maintain a separate parser for the .dcm files. If we choose not to merge them, I will update the file format documentation. Wayne
There is no hurry. I just think that once we have all the concerns on the table, that in the final solution having two files per symbol is pretty silly. Eventually an external conversion program could be written, so only one format need be supported within Kicad itself, (the newest format at that time).
I simply don't think having two files per symbol will do us any good at all long term, not when you start talking about web-based repositories and what not.
But a hypothetical migration to a new file format should be done as part of a comprehensive deliberation which would address as many current shortcomings as are evident at that time, so the conversion program only has to be written once, and users only would have to convert everything once.
I like extensible, self documenting text file formats, but when comparing say specctra DSN against XML, I think the DSN format is *far more* human readable. I know and love the parser that we have for that DSN format, and know that all a person needs to do to re-use that parser in another domain is simply supply it with a new keyword table and matching enums. (Ouch, this is not the search "keywords" we were talking about earlier.) That parser's advantages are that it supports C++ exceptions, and accurately reports input file line numbers, and can verify grammar by using recursive descent.
I remain fairly impressed with the specctra DSN file format (in a general sense, not speaking about the specific keyword grammar that we expect in it now).
Dick
| Thread Previous • Date Previous • Date Next • Thread Next |
