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
