kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

> I was thinking of using multiple symbols as one possible way to solve the
> multiple part per package and alternate body styles issue.  A 7400 would have
> four symbols.  One for each each gate.  A "swap_symbol" action could be used to
> substitute the alternate body style for each gate.
>   

Ok, that is important.  Have you ruled out the hyperlink concept for this?

It is clear that we will have exceptionally fast lookup capabilities for
GUIDs, and the form of the GUID which needs to simply navigate to a
different component can omit the library source portion, since it is
within the same library source. 

( component 74ABCand
:
(alternate_body_style GUID)  # demorgan's your uncle
)

can point to another component in the same library source.

Simple is a driver for me on this. 

But you have had your nose in the old eeschema library stuff longer than me.



>   
>> But by allowing only one symbol you can forget about the origin
>> discrepancy.  The one and only "base" symbol sets that.  You should also
>> of course be able to extend another component, and that component should
>> be able to be extended also, etc.  
>>
>> I would lean towards a single inheritance model myself, and like the
>> single pin and graphics container idea better.  It also has the
>> advantage of a single search space for things like (pin_del 12).  If
>> done this way, then take another look at the C++ structures with this
>> modification, and then I don't know that you need a separate class for
>> SYMBOL?  What do you think?  We could simply stop using the term also,
>> and in our discussions call it a 'base component' or 'graphics
>> component' or ________?  Open to ideas on that one.
>>     
> I'm not sure if a single table wouldn't be cleaner than separate tables for
> pins, graphics, and properties similar to LIB_DRAW_ITEM_LIST.  Since these
> objects are already derived from the same base class it may make sense to do
> this.  This way you avoid having to iterate over separate tables to draw or hit
> test a component.  You could add your actions like swap and delete to the base
> class like LIB_DRAW_ITEM and provide the appropriate action in the derived
> classes.  This could give you your "field_del" and "pin_del" actions without a
> lot of external manipulation by any parent objects.  You may to use the same
> base container class for your tables if you create separate tables.  That way
> if using multiple tables doesn't work out the way you envisioned it, it would
> be fairly easy to convert over to a single table.  You may have to code it an
> see how it works and go from there.
>   

Since parsing can be thought of as loosely resembling compiling, my
concern is speed and simplicity, extended over virtually every component
that needs to be loaded.  When doing the component field editor and
adding template fieldnames, I found it extremely ugly to have to
sequentially search that list for a field name.  If you start looking at
the algorithms to parse the components, it is very beneficial to use the
proper container for each category of item since it:

a) immediately reduces the search space by about 1/3.
b) gives you the ability to pick a container appropriate for that need
with a view to maximize speed.
c) pays you back on the parsing of every component, which is every
component.


The process of rendering the objects can easily be split into a series
of 3 for() loops, as can the hit testing be also.  This gives you an
inherent ability to control the sequence of the drawing of component
items.  graphics, then pins, then fields.   Or any other order that is
chosen, is simply a matter of re-arranging 3 for loops sequentially. 
Same for hit testing.

std::set is actually a reasonable container to consider for the pins and
also for the fields.  boost::ptr_vector might work for the graphics.

I will admit, this is looking like a major re-write of eeschema.  No
doubt about it.  But these are definite improvements to real problems,
with *lots* of enhancements.

Sometimes it is just simpler to lay a new foundation and start over than
it is to keep tripping or stubbing your toe on a bumpy road.  Put down
an autobahn, and then go like hell is what I am advocating here.  We are
moving into the holiday season where traditionally I have been able to
contribute more.  These changes appear to be too disruptive to do in the
current testing branch.


>> Maybe we do a series of *.h files with Javadoc comments describing the
>> classes and functions using comments and function declarations.  We can
>> generate html from that, and if it looks sound, folks could starting
>> coding implementation functions and classes.
>>     
> I think it would be helpful to see a skeleton of the objects with some
> documentation.  It should make the path from here to there easier to see.
>
>   
>> So back in December of last year I had mentioned I would do the *.h
>> files, maybe real soon now is the best time.  Right after a good night's
>> sleep and lots of coffee.  I could check in daily and others could add
>> their own edits and attach patches to email postings.  This way more
>> than one of us could churn.  We can put everything in one *.h file for
>> now, and generate javadoc html from that.  Later we can split up the
>> file.  BTW I would want to throw exceptions from the LIBRARY_SOURCE
>> functions and keep the UI out of there.
>>     
> I like this idea.  Some developers tend to ignore return errors.  Exceptions
> make it obvious you have done something wrong especially when it gets caught by
> top level wxWidgets exception handler.  Keeping UI elements out of the low
> level objects is a good idea.
>
> Wayne
>
>   
>> Jean-Pierre, do you think this is worth my time? 
>>