kicad-developers team mailing list archive
Mailing list archive
Re: exploiting human readability
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
> 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.
>>> 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.
>>> 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