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 : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
