kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 6/27/2010 4:56 AM, jp.charras@xxxxxxxxxx wrote:
> Wayne Stambaugh a écrit :
>> On 6/26/2010 2:50 PM, jp.charras@xxxxxxxxxx wrote:
>>> Wayne,
>>> I sent this mail to Kicad-developers list, but I believe  it seems lost
>>> for an obscure reason.
>>> (this is not the first time it happens)
>>> So, I send it directly to you.
>>> I apologize if it is a duplicate.
>>
>> JP,
>>
>> I didn't receive this email from the developers list.  Thanks for
>> replying to me directly because I wanted your input on this subject
>> before I made any changes.
>>
>>>
>>> Dick Hollenbeck a écrit :
>>>> 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.
>>>>   
>>> Aliases were designed to easily create components that are identical to
>>> a given component (the root component)
>>> In first version of Eeschema aliases were just a duplicate name for the
>>> root component ( like a symbolic link)
>>> and shared all the data (graphic items, fields, doc, link to a data
>>> sheet, keywords) with the root component and just have a different name.
>>> This was enough to handle components like 7400, 5400, 74ls00, 74HC00...
>>> Aliases can be used to handle components that are differents, but have
>>> the same graphic representation, like op amps.
>>> Many op amps have the same graphic data (same pins, same body) and using
>>> aliases to create a new op amp from existing op amps can be useful.
>>> But in this case, aliases but have their specific data sheet and
>>> keywords.
>>> This is currently the case:
>>> An alias shares with the root component all graphic data (including
>>> pins) and fields, but have its specific name, doc, keywords and link to
>>> its data sheet.
>>> Fields are currently shared, but could be easily specific, if wanted.
>>>
>>> If we are talking about internal representation, full aliases data can
>>> be handled by the root component without any problem.
>>> This is also true for library file format.
>>
>> The largest part of my proposed change in internal.  I think making the
>> aliases children of the component class will simplify the design of both
>> the library and library component classes.  It will also directly map to
>> what I am going to propose for the new file format which will do away
>> with the current two file design.
>>
>>> But I do not believe deleting a root component must also delete its
>>> aliases. This in not the behavior expected by users.
>>> When I delete only one component, I do not want to delete a lot of
>>> components, mainly if I used aliases to create different op amps that
>>> have only the same package.
>>
>> I had the opposite experience with the library editor.  When I deleted a
>> component that had aliases, it didn't actually delete the component as I
>> expected.  It renamed the component to the first alias and deleted the
>> alias.  I thought the alias page of the component properties dialog was
>> used to add, remove, and edit aliases and the remove component from
>> library button actually removed the component and all it's aliases.  I
>> can keep the library editor behavior as it is.  From my experience it
>> just didn't seem logical.
>>
>> Wayne
> In fact, I see 2 cases:
> An user want to remove only one component. Aliases must not be deleted;
> An user want to move the root component from a lib to an other lib.
> In this case, Aliases will be copied to to new lib, and deleting the
> root component and its aliases make sense.

If I'm not mistaken, this would be a new behavior for the library
editor.  It certainly be useful for users.  I can add this behavior as
part of my changes.  I may code it as a separate commit but I'll add it
to my TODO list.

> Also user could be prompted to delete or not aliases when exist.

I like this option.  If no one has any objections, I'll modify the
delete component button to prompt the user to ask whether to delete the
component and all of it's aliases or just rename the component to the
next alias name (current behavior) so the user knows exactly what
changes will be made to the library.

Wayne

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