On 1/30/2012 1:06 PM, Dick Hollenbeck wrote: > > Jean-Pierre and Tom, > > > Wayne came to stay at our house this weekend. He is a great guy, even > classier than he > comes across in his emails.
Dick, Thanks for compliment. I was thinking the same thing. Email does not even come close to revealing someones true character. I came away very impressed by what you have achieved during your life time and by way live your life. I am really glad I made the trip down for Denton to visit and I would do it again in a heartbeat. My son and I will never forget the hospitality that you and your wife extended to us. > > During our visit we talked about many things, one of which was an idea that > came in from > Tom last year. > > Attached is a sketch of a class would be compiled multiple times to remove > the drawing > code from the graphical objects, isolating it into a single class. The > advantage is that > we can use alternative output devices (and graphical or plotting libraries), > without > constantly adding member functions. The member functions we assume will > cause problems > linking these container objects as DLL/DSOs, in a way that we can put > scripting and > command line processors up on top of them. > > I sketched this out this morning, and it provides the basic idea. We > sacrifice > polymorphism in BOARD_ITEM::Draw(), but the overhead of PAINTER::Draw() is > minimal > relative to other bottlenecks. It will simply mean you call PAINTER::Draw() > almost > everywhere. > > To interpret the context of the code, we are assuming the following: > > 1) bottom end (data model) PCBNEW code will be linked into a DLL/DSO > > 2) bottom end (data model) EESCHEMA code will be linked into a DLL/DSO. > > 3) they will never be linked together, but might operate together under one > process. > > > This means we can multiply compile class PAINTER with either > > -DEESCHEMA or > -DPCBNEW > > There is no reason to have an inheritance tree in class PAINTER, since it is > multiply > compiled, separately linked. When and if we ever change > graphical libraries, we REPLACE it at compile time, not runtime. If possible, we may want to separate out the schematic item drawing code since the only application where it is use is Eeschema. This would simplify the design and prevent the drawing code source file from getting unwieldy. Some of the object drawing code is fairly lengthy so putting all of them in a single source file may be a bit much. It also might be useful to put the source files for the schematic drawing code in the eeschema folder since that is the only place where they are needed. There also is a need to create a third drawing class for component library objects derived from base class LIB_ITEM. > > Please let me know if you have any questions, and what you guys think. Tom > since this was > originally your idea, I wanted to bounce this off you also. > > Regards, > > Dick > > BTW, I have been told that I was spending too much time on KiCad, so my > contribution rate > is throttled down now to some hours on the weekend. Vacation time is over. > So the move > to PCBNEW millimeters will go slower now. > > Also, the increased productivity of our face to face meeting really brought > home how > inefficient a mailing list is for idea exchange. We might want to start > using another > medium for design idea exchange, maybe IRC, or whatever. (The developer's > list is > morphing into a user support mailing list, and it is hard to hear ourselves > think here > sometimes. Part of that is because folks have to join developers to submit a > bug?) Agreed. Talking to you directly for a few minutes around the kitchen table was more productive than hours worth of emails back an forth. Maybe even something like Skype or one of the open source alternatives with some type of whiteboard feature would be more effective at least for those of use who speak English. I may have to rethink the way I use email. Best Wishes, Wayne > > > > > > > > > _______________________________________________ > 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
