kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 6/24/2010 4:56 PM, Dick Hollenbeck wrote:
> 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.

This change is strictly an internal change.  Except for the proposed
changes to library editor delete component button behavior.  When you
see the file format proposal, these changes will make more sense.

> 
>>> 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.

I'll try to remember to incorporate these ideas when I submit the
blueprint for the new library file format along with some of the ideas I
have.  I want avoid turning this thread into a discussion on the file
format so that all of the discussion is part of the blueprint.  This way
all of the file format input is in one place so when I start coding I
wont have to dig through the mailing list to make sure I covered everything.

Wayne

> 
> Dick
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>