Description
KiBot recently added a "rail widener" panelize feature (INTI-CMNB/KiBot#953, implemented in INTI-CMNB/KiBot#954): a solid patch of extra rail/frame material at chosen outer panel corners, so pick-and-place photoelectric sensors get a bigger flat target without growing the panel's outer outline or overlapping a board. It's implemented as a KiKit FramingPlugin (kibot.panelize_plugins.rail_widener.RailWidenerFramingPlugin), driven by four extra arguments (which corners, depth, length, and the gap kept from the board).
The problem: KiKit's own pcbnew panelize dialog (kikit/actionPlugins/panelize.py + panelize_ui_sections.py) has no way to expose plugin-specific arguments. For any framing.type: plugin, the dialog only ever shows the generic Code/Arg fields — the user has to hand-write a JSON string into Arg, which is workable for KiBot's own YAML-driven usage but a poor experience for anyone using the rail widener directly from pcbnew's GUI.
Proposal: extend the framing section's type choices with railstb+widener/railslr+widener/frame+widener/tightframe+widener (one per base framing type that supports it). Selecting one of these hides the normal Code/Arg boxes and instead shows dedicated Widenercorners/Widenerwidth/Widenerlength/Widenergap fields. During preset resolution these get collapsed into the existing generic type: plugin / code / arg form (pointed at the rail widener plugin class), so the actual panelization/plugin-loading code path is untouched — this is purely a GUI convenience layer on top of the existing plugin mechanism.
I already have this working locally (branch rail-widener-gui on my fork) and would like to submit it as a PR — see the follow-up PR for the concrete diff. Note this PR only makes sense once KiBot's rail widener PR (INTI-CMNB/KiBot#954) is actually merged, since the generated arg JSON references that module path.
Description
KiBot recently added a "rail widener" panelize feature (INTI-CMNB/KiBot#953, implemented in INTI-CMNB/KiBot#954): a solid patch of extra rail/frame material at chosen outer panel corners, so pick-and-place photoelectric sensors get a bigger flat target without growing the panel's outer outline or overlapping a board. It's implemented as a KiKit
FramingPlugin(kibot.panelize_plugins.rail_widener.RailWidenerFramingPlugin), driven by four extra arguments (which corners, depth, length, and the gap kept from the board).The problem: KiKit's own pcbnew panelize dialog (
kikit/actionPlugins/panelize.py+panelize_ui_sections.py) has no way to expose plugin-specific arguments. For anyframing.type: plugin, the dialog only ever shows the genericCode/Argfields — the user has to hand-write a JSON string intoArg, which is workable for KiBot's own YAML-driven usage but a poor experience for anyone using the rail widener directly from pcbnew's GUI.Proposal: extend the framing section's
typechoices withrailstb+widener/railslr+widener/frame+widener/tightframe+widener(one per base framing type that supports it). Selecting one of these hides the normal Code/Arg boxes and instead shows dedicatedWidenercorners/Widenerwidth/Widenerlength/Widenergapfields. During preset resolution these get collapsed into the existing generictype: plugin/code/argform (pointed at the rail widener plugin class), so the actual panelization/plugin-loading code path is untouched — this is purely a GUI convenience layer on top of the existing plugin mechanism.I already have this working locally (branch
rail-widener-guion my fork) and would like to submit it as a PR — see the follow-up PR for the concrete diff. Note this PR only makes sense once KiBot's rail widener PR (INTI-CMNB/KiBot#954) is actually merged, since the generatedargJSON references that module path.