kicad-developers team mailing list archive

[Moses O McKnight <moses@...>]

On Thu, 2008-07-17 at 10:03 -0500, Dick Hollenbeck wrote:
> 
> 
> On 7/16/08, Moses O McKnight <moses@...> wrote:
> Hi Dick,
> 
> Yes, I'm doing this for panelization.
> 
> I don't know how it worked before because this is the first
> time I tried
> it.
> 
> I expected it to import the board into the current file,
> without
> changing the file name, or current file settings.
> 
> This whole concept seems a bit awkward to me for pcbnew. I would have
> added this functionality to the gerber viewer and not to pcbnew. If
> the gerber viewer had this functionality along with the ability to
> save to panelized gerbers, this might have been a better strategy in
> an alternate world.


That sounds pretty good.


> I'm not sure that the component not moving had anything to do
> with with
> trying to append the boards. It would work sometimes but not
> work most
> of the time. I haven't tried the same operation on the
> original board
> yet.
> 
> This last paragraph is not clear. Please elaborate.

When I appended a board to another, and then tried to move the board,
everything moves except for one component. I don't know if this has to
do with appending the board or not because I haven't tried to move the
whole board in the original file. The problem is somewhat intermittent
as well.

> I think I see several other bugs as well and maybe some ideas
> for
> improvement. One thing is that pcbnew seems to lose the track
> and via
> sizes randomly. Sometimes they will be there when you open
> pcbnew up
> and then later they will be gone (they don't come back
> either). I
> haven't had them vanish during a session though. My idea is
> that maybe
> one could define a list of track and via sizes that would stay
> with the
> file until you changed them on purpose. And maybe have via
> hole sizes
> for each via size.
> 
> I agree. I would like to find time to implement "net classes". A
> net class would contain a number of attributes of tracks and vias.
> Then any net could be assigned a net class, and more than one net
> could be assigned the same net class. There would be a default net
> class for any net not assigned a net class. This would significantly
> enhance the routing within pcbnew as well as the specctra export to
> freerouter. If you have not tried freerouter yet, do so to get a
> clearer idea what I am talking about. You can also read the specctra
> file format spec. (By the way, the real value of free router to me
> has been its superior push and shove manual routing, not the
> autorouting.)

That sounds good. It looks to me like there are a number of things not
very "object oriented" about kicad. From just a cursory look there
seems to be a mixture of classes and standard C programming.

I wrote a program for windows a number of years ago in VC++ that was
basically a page layout program, so it had quite a bit in common with
kicad in some ways. I had a main document class that contained all the
objects associated with it. It saved and loaded itself, and every item
did the same. Each item was derived from a base class that allowed them
to be accessed through a generic pointer, and it knew how to do all
operations on itself. The program had unlimited undo/redo for all
operations. So I'm hoping that if I can get enough time to really dig
into kicad I might can help fill in some of these things.

> 
> The pcbnew "history mechanism" for via and track attributes could
> easily be replaced with net class support.
> 
> I cannot think why your history records are occassionally
> disappearing, I don't recall experiencing that. But I would not be
> inclined to fix it given my statements above about net classes.
> 
> 
> 
> Another idea is to either change the net names when you append
> a board
> so there are no nets connected between boards, or make each
> board be its
> own object so we could re-read a netlist for each board.
> 
> 
> I see you also are struggling with the whole concept of board import
> into pcbnew. See my comments above about doing it in gerber viewer as
> an alternative.

You are probably right. I wonder how hard that would be to implement?

> I'll be looking at the source code and trying to see if I can
> find out
> how things work so I can help work on some things if I get
> time. Any
> pointers as to how the code is structured would be great!
> 
> 
> Run doxygen on the code, search this list for instructions on how to
> do that. Then look at the class inheritance diagrams created in the
> html pages generated.
> 
> Then get a good editor which has built-in multi-file grep
> functionality. I use jedit.
> 
> Dick

Thanks for the information. I'll run doxygen soon and start reading.
I've imported the kicad source tree into Code::Blocks IDE which is also
based on wxWidgets and runs in linux and windows.

Moses