>> 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. Small potatoes, but if it simply search and replace. Most calls are nested twice, so this reduces the pushes from 8 to 2. 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. 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
