[FEATURE] Cleanup Tracks and Vias/Global Deletions/Post Variant Zone Refills

[willpuckett]

Is your feature request related to a problem? Please describe.
First of all thanks again for all the work on Footprint replacement. I was able to test it out a little more over the weekend and it's really awesome.

The revxlp keyboard has 6 variants: pcb, top, and bottom plates in 10u and 12u sizes. I'm trying to achieve parity between the original project's 6 variants and the KiBot outputs, which may be beyond the scope of the intended use of footprint replacement, but is working pretty well. I made a rough demo using KiBot to successfully change board outlines and swap components.

The main three issues I see at this point:

1. Cleanup Tracks & Vias: Being able to execute Cleanup Tracks & Vias after foot print replacement seems to work well in the gui to remove traces orphaned by the change in board outline. Is it possible/ would it be possible to be able to execute this from KiBot? Or is it possible to select and filter all tracks and vias outside the board outline in order to remove them?
2. Global Deletions: The top and bottom plates do not need any of the traces/vias. Is it possible/would it be possible to execute Global Deletions... Tracks & Vias on a variant to clean these up?
3. Zone Refills: As discussed in issue [FEATURE] Option to apply a variant to be used by the preflights #388, zone fills happen before the variant is made, resulting in extra copper outside the board outline in the case of the demonstration project. Is the best option to generate the variant_sch and variant_pcb via kibot, and then rerun the outputs passing the variants as outlined in [FEATURE] Option to apply a variant to be used by the preflights #388?

[set-soft]

The problems here are:

1. The Python API doesn't have a simple mechanism to trigger it
2. Trying to do it by performing the tasks done by KiCad using the Python API is a bad idea because KiCad developers doesn't maintain the API from each major release to the next. So something that might work today will most probably fail the next year. In particular with things like analyzing the connectivity.
3. From the GUI the process is quite interactive, you have to enter the dialog, start the analysis, wait until is done, catch things like "the board needs refill", detect the process ended (which in my experience is unreliable because they like to change the messages) and then confirm the changes.

So I don't know if I'll implement it.

[willpuckett]

Certainly understandable!