On 10/09/2010 10:01 AM, Wayne Stambaugh wrote: > On 10/8/2010 10:50 PM, Dick Hollenbeck wrote: > >> >>>> Due to all changes, a new branch is reasonable. >>>> I assume the "new branch" is (in your mind) actually a new branch pushed to >>>> Launchpad, >>>> not a subtree of the current testing branch >>>> But (this is just an idea, I am not saying this is a good idea): >>>> Keep the testing branch, and just create a new tree like testing/eeschema2 >>>> in >>>> the current testing branch and keep the current version in >>>> testing/eeschema. >>>> >>>> >> >> OK, as soon as it evolves to something more than a dream or document, I >> think the best path will make itself clear. Whatever minimizes pain, if >> it hurts, don't do it. >> >> I think the graphics modularization in eeschema is evolving nicely due >> to all the work done by everyone, plotting too. My thanks to Wayne, >> Lorenzo (plotting) and Jean-Pierre. >> >> And Jean-Pierre the Gerber work is pretty substantial and ambitious. >> Nice job. >> >> Regarding the two dimensional transform matrix, I wonder if we should: >> >> A) typedef the transform to hide the [2][2] with a typedef, and then >> B) pass it by const & reference using that typedef. >> >> >> What I see now looks like it causes the machine to push 4 integers each >> time a call is made. Passing a reference (i.e. a machine pointer) cuts >> out 3 pushes. >> > And pops off the stack on the way back out of the Draw method. The Draw > method takes a lot of parameters. I'll bet if someone were clever > enough they could turn all these parameters into a simple self > initializing class that covers most of the common drawing configuration > and just pass a reference of it to the Draw method. Maybe a few derived > versions for special drawing configurations such printing or plotting. > Just food for thought. > > >> Small potatoes, but if it simply search and replace. >> >> Most calls are nested twice, so this reduces the pushes from 8 to 2. >>
Two little sleep, too nights in a row. :) Its an array, so only its address is being passed. Dick >> The graphics functions are now effectively doubly encapsulated, once >> with the objects we have that use Draw() and then the graphics >> abstraction layer. For simply drawing I see it getting easy now to swap >> out stuff underneath this nice layering. That was "for simply drawing", >> a little harder is the interactive dragging operations, box rubber >> banding etc. >> >> Any way Kicad has evolved nicely *under the hood* in the last 4 years. >> > There is much more forth coming on this front. I am going to move all > the component library object editing code in symbdraw.cpp into the > appropriate objects. Library component objects will know how do draw > themselves while they are being drawn, moved, re-sized, etc. This > should be the last of the external manipulation of the component library > objects. At this point I should be able make all the members private > and then begin the same process on the schematic objects. > > Wayne > > >> Dick >> >> >> >> >> >>>> In my mind, testing/eeschema2 is the new tree containing new files and >>>> subtree >>>> and can be seen as "the new branch" >>>> Compiling files in testing/eeschema2 could made on demand, using a build >>>> option >>>> for instance. >>>> testing/eeschema2 could contains only new files, an use files in >>>> testing/eeschema2 as long as they are compatible (if any). >>>> This is perhaps a convenient way to work on the old and new eeschema >>>> version >>>> and merge bug fixes or enhancements in common files. >>>> Common files can be updated (graphic functions, basic classes, dialogs for >>>> error reports ...) both for "old" and "new" eeschema versions more easily >>>> inside the same devel branch than if there are 2 branches. >>>> When eeschema2 becomes eeschema this switch will be more easy. >>>> >>>> >>> I like this idea. It may get more people involved in building, testing, and >>> bug reporting if you do it this way. When I wrote the wxGCDC code I thought >>> maybe one or two other people might give it a try. I was surprised by the >>> number of people who tried it out and commented on it. There was even a few >>> bug reports and fix commits on this code. I doubt this would have happened >>> if >>> I would have done this in a separate branch. I'm wondering if Hueter would >>> have taken this route with his GAL code if we wouldn't be farther along the >>> path of having an improved graphics layer. It may be worth the extra >>> effort to >>> do it this way. >>> >>> 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 > > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
