kicad-developers team mailing list archive

[Jerry Jacobs <xor.gate.engineering@xxxxxxxxx>]

On Fri, Jun 25, 2010 at 3:56 AM, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> wrote:
>
> 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.

Maybe another thing is to split it complete from the kicad core. So
create a real library written in ISO C++ so people who want to write
plugins and language bindings will be more happy than the hacked code
to read and write files in the current codebase. Because if you find
some software which can do something with the kicad file formats they
all write their own parsers/handlers and that is a bit of a pain to
keep the other people updated for the new upcomming file format(s).
Also if you dont use any existing library be used in your library like
wxwidgets it is portable to everywhere and also for people who want
something different than wxwidgets like Qt/Gtkmm etcetera. Than you
will see much more tools and utilities than now.

Maybe you should have a look how dxflib and podofo pdf library. Then
are very powerfull libraries and very consistent with names and
classes. In my opionion this is a pre for a new file format
reader/writer.

Kind regards,
Jerry Jacobs