← Back to team overview

kicad-developers team 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
>> 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.


>> 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

Follow ups