kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 06/24/2010 03:36 PM, Wayne Stambaugh wrote:
> I don't know how fancy it will need to be. The only thing I know that
> aliases are used for in EESchema is listing and searching for
> components.  Searching components list of aliases would not be any more
> complex than searching the library for an alias.
>
>   
>> This is a large demotion for aliases.  Whoever coded the original UI
>> behavior (Jean-Pierre?) might be expected to voice some concern over
>> this.  Aliases suddenly become less than full fledged components from a
>> UI perspective.  I am not sure what the purpose of an alias is, if not
>> to be available at the UI for use as an equivalent to a component. 
>> Maybe you can make up for this some other way...
>>     
> Aliases aren't really full fledged components in the current design.  In
> other words, there is no drawable object (pins, rectangles, arcs,
> fields, etc.) information in an alias.  Aliases are simply some
> description strings and a pointer to a component.  Moving the aliases
> into the associated component means that component libraries will only
> contain components not components and aliases.  From a users point of
> view, there will be no difference in the alias and component
> information.  Only the internal representation will change.  I'll
> certainly wait for JP to comment.
>   

The user's point of view is probably the most important view.  If you
can preserve that then I don't need to question what happens behind the
curtain if it makes life easier.  It is my understanding that an alias
DOES have pins from a users point of view, the same pins that the root
(non-aliased) component has.

>> Please get this stewing also:
>>
>> I think we should also eventually kill off the notion of a library
>> search path, and implement Lorenzo's idea about
>>
>>     <logical library>.<component_name>
>>
>> when we store things in the schematic.
>>
>> https://bugs.launchpad.net/kicad/+bug/575810/comments/11
>>
>> I don't like to feel like I have to win the lottery to have eeshema find
>> the component I put in my schematic.  Two times in the last 2 years, I
>> have pulled up my schematics and had my components mysteriously changed
>> right out from underneath me.  Bug 575810 is real, but could be dealt
>> with at a later point in time, or now if it saves writing yet another
>> conversion program later.
>>     
> I've been bit by this one as well.  I already have this documented in
> the new component library file format document I've been working on.
> Hopefully I'll finish up this document in another week or so.
> Initially, this will not be of any use with the current schematic file
> format.  I was planning on fixing it when the schematic file format is
> moved to the DSN lexer.
>   

Well correct, this 575810 bug is more of an issue with the schematic,
and not with the library format.  No point in messing with the current
schematic format if you are up to eventually changing it wholesale
later.  A conversion program at that time could:

1) use the root name of each library in the existing search path as a
logical library name.

2) create a personal mapping table ("personal" == valid across all
projects) which includes the standard libs we distribute.

3) For each component in each schematic:  "find" using the existing
library search path algorithm each component in the old schematic and
replace that name with <logical_library>.<component_name> in the new
schematic.

4) Support a project specific override to the personal mapping table,
and put libraries that were in a particular project's search path, but
which were not "standard" libraries, into the project specific mapping
table override.


The new eeschema schematic component algorithm is a matter of searching
the project specific override mapping table first, then the personal
mapping table *iff necessary* to find a logical_library name, and then
from the found mapping table entry, the actual library.

Dick