kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 05/11/2012 09:54 AM, jean-pierre charras wrote:
> Le 11/05/2012 14:44, Dick Hollenbeck a écrit :
>> On 05/10/2012 02:34 PM, jean-pierre charras wrote:
>>> Le 10/05/2012 18:21, Moses McKnight a écrit :
>>> ...
>>>> In the new designs, when you add a symbol, does it have a tag telling which library it came from? Currently if two libraries have
>>>> a part with the same name, the part will be pulled from the library that is listed first in the list. If the part on the schematic
>>>> had a tag for the library it came from, things would be a lot more flexible.
>>>>
>>>> Thanks,
>>>> Moses
>>> This is false, in fact things would be a lot less flexible.
>> We are all entitled to our opinions.  I think the current design is broken, and the
>> ambiguity of which "partname" is chosen, is a bigger problem than any you mention below:
>>
> Well, my answer was very unclear,
> because in fact not relative to the future library handling (SWEET),
> but rather to the current kicad code, with some enhancements relative to the components identification.
>
> I was thinking Moses was interested by modifying the components identification in the current Kicad version
> (New designs can be understood like the current Kicad version with enhancements,
> not necessary the future SWEET version).
>
>  From the first "Kicad preference questions" mail,
> there is a lot of new questions, some topics have changed
> and we are far from first "Kicad preference questions"
>
> Currently, it is no easy to add the library identification without breaking some things.
>
> The next (should we say new?) Kicad design is made to do a more powerful (by far) component identification.
> Therefore, and obviously, it will fix some issues that cannot easily fixed now just by some current code enhancements.

Well said Jean-Pierre.

If I can say it another way:  for well over 2 years I do not remember committing one line
of code to Eeschema, that was related to an Eeschema enhancement to existing code. 
Instead, I created the /new directory.


I have, and continue to go quiet any time someone says they want to perform elbow surgery,
trying to make this thing fly.  My preference has been to start with the wings, and do it
bottom up, down in /new.  I really don't have time to argue about what I am doing down
there, and did not want to get in the way of anything anybody else was working on up in
the normal places.

Wayne and I discussed the SWEET design at significant length, both on list and off list
for a LONG time before any code got written.  Then Wayne, being the extraordinary team
player he is, made sure what we discussed got documented.  Not so that it could not nor
would not change, but rather so it did not get forgotten.

After starting with the coding, the SWEET spec did change a little, and it will probably
change again as we back it up with graphics support. 

But one has to recognize that we are way way way past the hypothetical, or the "drive by"
suggestion phase.

The SWEET language is fairly well documented at this point, (except for the multi-part
stuff, on which I think there is still some minor disagreement).  I think people still
struggle to understand the parts list concept, but I don't know that that is big a problem
yet for anyone, except "would be" assistant coders.


Dick