Re: [Gerbv-devel] Selection is now in CVS
Brought to you by:
spetm,
thepurlieu
From: Julian <the...@gm...> - 2008-04-06 20:24:49
|
> Cool thing, Julian. I actually have some ideas for selection, like > marking a net and get information on what aperture it uses etc. But this > is a major step for gerbv. Yes, I think a right-click menu option to give some info on the net would be really nice. Maybe even telling the user what line it is in the gerber file would help too...especially for us gerbv developers who need to track down where exactly a messed up net is inside a test file. Maybe I can code in the hooks to do this through a right-click menu, and someone else can do the info stuff. Maybe this ties in with some of your future analysis ideas Stuart? > > Though editing gerber files is from my point of view like hand patching > the object file to fix a program, but I see other uses for this. I see your point. But sometimes things like last minute cleanup and panelization are probably just as easy to do after you have designed the board in a CAD program. And things like drawing in special routing designs in a board (in the "fab" gerber layer), which currently you can't do in PCB. > > 1) mainly for Stefan: Selection does not currently work with polygon > > fills. Currently the selection code looks for the "net" that lies > > within the selected area. For most elements (flashes, aperture lines, > > etc), the entire element lies within a single "net". However, polygons > > currently span a new net for each vertex. I propose we modify the > > polygon structure to store a polygon in a single net. Stefan, what do > > you think? If we do this, then effectively every Gerber element will be > > nicely packaged into a single net, so it will be much more > > straightforward to handle selections/modification/etc. Ok, I will work on this. It also help reduce the memory footprint of an image even more than now. For boards with large ground planes, PCB outputs a zillion polygons for them, so changing to 1 net per polygon will save quite a bit of memory since the net count will be much lower. Maybe I'll try some test cases before and after and try to quantify the savings. > I have cairo compiled in, but I managed to remove elements despite being > in "fast" mode. So the only problem I see is when cairo is not compiled > in at all. Just simply disable pointer tool and matching sub thingies. You must have checked out CVS after my latest commit yesterday...I went ahead and coded the GDK rendering stuff late yesterday so the selections work in FAST mode now. A much better solution I think. > Really amazing work, Julian. Thanks guys. Cheers-- Julian |