kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 10/4/2010 5:38 AM, Brian Sidebotham wrote:
> On 1 October 2010 21:42, Wayne Stambaugh <wstambaugh@xxxxxxxxx> wrote:
>> Since the discussion has died down on the library structure.  Here is a recap
>> of the discussion.
>>
>> 1) The current concept of component will be replaced by symbol which is the
>> graphical representation of a component.
>>
>> 2) The current concept of aliases will be replaced by component which will
>> contain it's own fields but can share a symbol with other components to save
>> memory.
> 
> (1) and (2) sound great, sharing a symbol would be very beneficial for me.
> 
>> 3) Symbols may be shared among all components within a library definition.  In
>> other words, symbols will not be shared across libraries.
> 
> Although it would obviously be better to be able to share symbols
> across libraries, I can see why you want to limit it to sharing just
> between components in the same library. It will be still be very
> beneficial for me.

You will be able to share symbols within a library.  It will be within the
scope of the current definition similar to the current file format DEF/ENDEF
blocks.  This will be obvious when I publish the new file format document.
This is not cast in stone.  I'm willing code just about any feature as long as
the benefits out weigh the additional complexity and the problem cannot be
solved more elegantly elsewhere.

Wayne

> 
>> 5) Create a separate library user_defined_file_name.lib when libraries are
>> found containing alternate body styles (DeMorgan).
> 
> I read Jean-Pierre's response to deMorgan symbols and certainly before
> I read it I could not understand why anyone would want to use
> different symbol styles for the same part. However, having read his
> response, it does make sense.
> 
> Some code I recently saw had double negatives all over it, which human
> brains cannot process very well. For example:
> 
> bool not_ready = false;
> 
> if( !not_ready )
> {
>     // is ready...
> }
> 
> is a lot less readable than:
> 
> bool is_ready = true;
> 
> if( is_ready )
> {
>     // is ready...
> }
> 
> ...and so I ended up with two functions in the code to cover the
> double negative check and encapsulate it in a function name that made
> logical sense when reading it, but ultimately they were both just
> encapsulations for the same bool. The code is 100% more readable with
> the two encapsulation's though.
> 
> I guess the same is true for large logic diagrams, but I have never
> used alternative styles and would probably never had considered them
> to make logic diagrams easier to understand until Jean-Pierre's post.
> 
>> 6) Merge the footprint list into the FOOTPRINT field and the data sheet
>> definition string to the DATASHEET field in the new library structure.
> 
> This will be a nice improvement, so that everything can hopefully be
> moved into one dialog for editing a component's properties.
> 
>> Before I submit the new file format document for comment, would you prefer a
>> more readable but larger file format:
>>
>> ( arc
>>  ( start_point 1000 1000 )
>>  ( end_point 1500 1500 )
>>  ( start_angle -45.0 )
>>  ( end_angle 45.0 )
>>  ( unit 2 )
>>  ( line_width 1 )
>>  ( fill_type none )
>> )
>>
>> or a less readable but more compact file format:
>>
>> ( arc ( 1000 1000 ) ( 1500 1500 ) -45.0 45.0 2 1 unfilled )
>>
>> Let me know and I will make the necessary changes to the file format document.
>>
>> Wayne
> 
> I much prefer the first more verbose version as it is much easier to
> decipher and will make writing parsers much easier.
> 
> Thanks for your efforts Wayne!
> 
> Best Regards,
> 
> Brian.
> 
> _______________________________________________
> 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
>