Make KiKit more scripting friendly

[yaqwsx]

• makeGrid misses the tolerance option. This is not a problem per-se, but makes writing custom scripts much easier.
• relocate expandRect from panelize into common
• polygonToSubstrate should also but in common or utils
• implement breakLinestring
• document the common package
• implement panel.addAnnotation

[mairas]

I've been an obedient guinea pig for the current API. I am creating a two-board design which I would like to like to have manufactured and assembled as a multi-board panel.

Here's the script I came up with: https://gist.github.com/mairas/f1531ec54dd04aad01e922324e6affa6

With just the panelize UI script to follow, the process was quite painful, but that's what you get by being a guinea pig... In the grand scheme of things, the API would seem to fulfil its purpose and with some examples and (in a perfect world) a bit more documentation, I think it would be quite straightforward to use. As it is, some things could be improved, however.

My observations:

• The dummy framing substrate feels like a kludge, and the function to create it is in kikit.panelize_ui_impl, which shouldn't be required. I wonder if that could be automatically generated together with frames or rails?
• Having to manage the tab, backbone and frame cuts manually and then feeding them back to the panel object feels unnecessarily complicated. Could they be automatically stored?
• Having to enter different cut widths repeatedly felt a bit redundant, and experimentation was often required to understand what each argument was doing.

All in all, good stuff!

[yaqwsx]

Thank you for the feedback:

• I am not sure if the dummy substrates are a good way to go. The idea was to define partition line building algorithms only on substrates. I haven't come up with anything simpler. It is true, that having the functions for building the substrates only in UI is wrong. There should be a separate function (probably in panelize) that does the "heavy lifting" and the UI functions should only parse the user input and invoke the functions from panelize.
• This is by design - when you make a tab and the cuts are returned to you allows you to easily render one group of cuts as V-cuts and the other as mouse bites. It also allows you to post-process them (e.g., prolong them, filter them, etc.). I think putting this inside the panel class would make it clumsier.
• Here I am not sure if I follow - which cut widths do you refer to? Could you be more specific?

[mairas]

I am not sure if the dummy substrates are a good way to go. The idea was to define partition line building algorithms only on substrates. I haven't come up with anything simpler. It is true, that having the functions for building the substrates only in UI is wrong. There should be a separate function (probably in panelize) that does the "heavy lifting" and the UI functions should only parse the user input and invoke the functions from panelize.

Given that the dummy substrate is only used in partition line building, maybe the it could be handled internally in buildPartitionLineFromBB? The frame offsets could just be input arguments for partition line building. Or -- I'm just throwing ideas here -- if frames or rails would be constructed before calling buildPartitionLineFromBB, could the actual substrates be used for partition line building, thus doing away with having to use the dummy substrate altogether?

This is by design - when you make a tab and the cuts are returned to you allows you to easily render one group of cuts as V-cuts and the other as mouse bites. It also allows you to post-process them (e.g., prolong them, filter them, etc.). I think putting this inside the panel class would make it clumsier.

You still could store the different groups in panel as public members that could be accessed and modified. That would allow the user to ignore handling them in regular use cases. But you could lose some generality in doing so, and I suppose it's a matter of taste. That's definitely not a dealbreaker.

Here I am not sure if I follow - which cut widths do you refer to? Could you be more specific?

You might want to ignore this. :-) It was me being confused, I think. I was referring to the different "space" values in the CLI, and also misunderstood the hcut and vcut params of renderBackbone. There are many parameters to enter simply because there are many different that need to be separately configured!

[SebastianGrau]

While you are at it, @yaqwsx, could the TabAnnotation class be refactored, so that it could expose the props when created with the fromFootprint static method? That would allow to provide tab options on a per-tab-footprint base. And it would help me tremendously in exploiting the TabAnnotation class for my own coil-laying algorithm 😁

I would gladly contribute the changes, if you think this is worth it.