On 1 October 2010 21:42, Wayne Stambaugh <[email protected]> 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.
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
