kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@xxxxxxxxx>]

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.

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