kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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