Configured CLI to allow 'manual' option for layout.

[Andrew-Collins]

This places additional boards at specified locations. Also added 'destination' option to layout, to specify the destination of the source board for all layout types.

New options for the 'manual' option are 'boards' and 'locations'. Both are lists, and could be changed to a dictionary or other format if that is preferred.

Tested the following:

• Grid layout with destination (need to use --post 'origin:' to see the effect)
• Manual layout with no additional boards
• Manual layout with multiple additional boards
• Manual layout but 'locations' and 'boards' options are different length (fails with message)
• Dump to preset file

Let me know if you have any questions, more to come.

[Andrew-Collins]

The application for this is primarily putting multiple different boards into a single panel. I originally wrote a Layout plugin to do this, but thought this is a generic enough task, and found that there was existing demand for this (#242). So I decided to roll it into the CLI.

If you are happy with this justification then I will address your concerns above, and then move onto docs and tests. Otherwise I'll close the PR and put a Layout plugin example somewhere for people to find.

[yaqwsx]

I am willing to merge such a feature. However, we have to find a clean way of UI for this. And I am still trying to figure out what's the right way.

One thing I came up with is: Let's always take a single source file. The source file could be either a single board or a board collection. Board collection would be either a path to a JSON file or directly JSON-encoded content that describes board mapping. The structure of the JSON can depend on the layout plugin used. For the manual layout, we could have something like this:

[
	{
		"board": "path/to/board.kicad_pcb",
        "source": {
			"tolerance": "10mm"
		}
        "pos": ["100mm", "20mm"]
	}
	{
		"source": "path/to/another/board.kicad_pcb",
        "pos": ["100mm", "20mm"]
	}

The semantics is as follows:

• we expect a list of objects.
• The objects must have board (path to board) and pos (target coordinates) attributes.
• Optionally, the user can specify the attribute source that will be merged with the source preset specified via --source. So, you can just override the source specification for the particular board. This is necessary if you want to extract multiple boards from a single bard.
• the position attributes should respect the common KiKit conventions for distance specification.

What do you think about this proposal? I think with this feature implemented, we could also support #533.

[Andrew-Collins]

That sounds good to me, I'll get onto it hopefully today. I'll use the following json template, as it seems closer to what you described:

[
	{
		"board": "path/to/board.kicad_pcb",
                "source": {
		        "tolerance": "10mm"
		},
                "pos": ["100mm", "20mm"]
	},
	{
	        "board": "path/to/another/board.kicad_pcb",
                "pos": ["100mm", "20mm"]
	}
]

[Andrew-Collins]

@yaqwsx apologies for the bump, didn't mean to ping you.

[snhobbs]

What's the next steps for this? I started putting together a similar separate CLI that does the same thing with a different input method: https://github.com/snhobbs/kikit-multipanel. Is it better as a separate tool or integrated into the existing CLI?

[yaqwsx]

Hi! Andrew put good arguments, so I want this feature to be merged into KiKit. I am postponing merging this, as there two upcoming tasks on KiKit roadmap, that will make this feature more streamlined and better working:

• the first one is internal refactoring where the goal is to remove all the "feature" methods from the Panel class. At the moment, the panel class is too long, hard to maintain and to extend. Instead, I want individual features to be in separate files. This will have (I hope a good!) impact on scripting. It will help us to fix #283.
• the second is the change of the geometry engine. At the moment we reach botch, functionality and performance limitations of Shapely and I would like to switch to cavalier_contnours. With this change, we can rework the partition line building algorithm that should end up working better for arbitrary layouts.

[snhobbs]

Great! Can these be made into issues with a bit of background? I'd love to get into them so this can be officially added in!