kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

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.
> 
> 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     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>