kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 6/24/2010 6:53 PM, Brian Sidebotham wrote:
> On 24 June 2010 21:36, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> wrote:
>> On 6/24/2010 3:44 PM, Dick Hollenbeck wrote:
>>> On 06/24/2010 02:19 PM, Wayne Stambaugh wrote:
>>>> In preparation for the forth coming changes to the component library
>>>> file format, I would like to make some changes in the design of the
>>>> component library object format and the component library editor behavior.
>>>>
>>>> The current component library design creates aliases as a stand alone
>>>> objects that reference the actual component object.  The component
>>>> object also keeps a copy of the alias information (strings) in a
>>>> wxStringArray.
>>>
>>>
>>>>  It seems to me that an alias has no meaning without the
>>>> associated component and keeping a copy of the alias data in the
>>>> component object is redundant.  I propose that the component object
>>>> maintain the list of it's alias objects and only components are added to
>>>> the library object.
>>>
>>> The above 2 sentences seem to contradict each other.  Can we assume that
>>> last one is what you intended?
>>
>> Oops!  You are correct it is the last one.
> 
> If I understand correctly, what you want to do is move all aliases of
> a component into the component object? I think this would make a good
> improvement for some future uses of aliases.
> 
> At the moment, aliases are not very powerful because of some limitations.
> 
> I don't know whether you caught any of the heavy symbol library
> discussion a few weeks ago, but a heavy symbol library can be
> implemented much easier is aliases are made a bit more powerful.
> 
> At the moment for example, I could create an alias which has a
> different footprint, but not an alias that has a different value. It
> would be another step towards good support for a heavy symbol library
> to be able to change the value of aliases. As well as this, aliases
> really need to support the template field names. At the moment you
> cannot have these fields in an alias. This would allow aliases to be
> used as a heavy symbol library, where only one graphic would need to
> be created.
> 
> Further on from that, aliases would be easily selectable via a pop-up
> list box or similar. One of the biggest time wasting parts of a heavy
> symbol library (if taken to it's extreme) is that simply changing a
> value of a passive component has to be done by replacing the
> component. If a hotkey can be used on a component when editing a
> schematic in eeschema to bring up a listbox of all of the aliases of
> the component, one can quickly be selected to change the value of the
> part.
> 
> This sort of thing works well when you need to change things like SMT
> electrolytics, as you would simply select by voltage and capacitance
> and the correct case size footprint would come from the alias. There's
> no risk of forgetting to change the footprint because you've altered
> the value.
> 
> I just wanted to give a possible good future use for aliases in case
> any of this is useful whilst you are working in this area.

Brian,

This is all really good information.  Hang on to it until I submit the
blueprint for the proposal for the new library file format.  The new
file format proposal I'm working on already covers a lot of what you
have listed above.  I want to try keep all the discussion about the new
file format in one place for my own sanity and to make sure nothing gets
lost.

Wayne

> 
> Best Regards,
> 
> Brian.
>