kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 10/7/2010 10:30 AM, Dick Hollenbeck wrote:
> 
>> 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?

Absolutely not.  I was merely thinking out loud.  If the hyperlink concept can
fulfill our requirements to support alternate body styles and with less
complexity.  I'm all for that.

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

That much is certain.  Much longer than I care to think about.

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

If you rewrite EESchema, then I don't see how you would have any choice but to
create a separate development branch.  The holidays are typically when I have
the more free time available as well.

Wayne

> 
> 
>>> 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? 
>>>     
> 
> 
> 
> _______________________________________________
> 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
>