kicad-developers team mailing list archive
Mailing list archive
Re: File naming policy.
>> Due to all changes, a new branch is reasonable.
>> I assume the "new branch" is (in your mind) actually a new branch pushed to
>> 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.
Regarding the two dimensional transform matrix, I wonder if we should:
A) typedef the transform to hide the  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
Any way Kicad has evolved nicely *under the hood* in the last 4 years.
>> 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.