Clarifying the GUI Panelization workflow

[gwideman]

I'm glad refinement of this awesome add-on continues!

As the "Panelization GUI" is the on-ramp for new users, I would like to suggest that the doc with that title could be a little clearer about what the intended workflow is.

First, trhe sentence "The GUI is designed to be run in a standalone instance of Pcbnew (not executed from a project) as the generated panel replaces the currently open board" is confusing and possibly alarming.

This appears to say that if the user doesn't do the sequence of operations correctly, the GUI will overwrite the existing kicad_pcb file. In which case a workflow step is needed to first copy the existing board to a different "panel" folder, to ensure that the original is not overwritten.

However, I think this sentence might be trying to say that running the GUI will simply close whatever board is open in the running instance of PCBNew. So if the user wants to keep the board open in PCBNew, they should open a second instance of PCBNew to perform the KiKit Panelization GUI steps, so it can create it's own board for the panel, without disturbing the first instance of PCBNew. This way the user can return to that open board easily -- for example to make adjustments to components or traces to avoid conflicts with panel tabs.

It would also be helpful to know where (in what folder) Panelization GUI will place the result file and what it will name that file -- or does it just generate the result into PCBNew, and it's up to the user to use the PCBNew UI to save it with a name and location of their choice?

Finally, the doc page says "The panelization feature of KiKit is also available via GUI in the KiCAD's PCB editor (Pcbnew)." While true, I think this creates the expectation that the GUI is a possible everyday way to use Kikit panelization, which I don't think is true. The next sentence does say "The main use-case for the GUI is to quickly construct the desired KiKit command...", and I believe that's because there's no way to save and later reload the settings into the GUI, right? So it would be good to clarify to the user that for everyday use, they will need to use the CLI. The GUI is not a way to avoid having to use the CLI, just a way to prepare to use the CLI. (I'm fine with that, I'm just suggesting making that aspect clear.) Also -- does that mean that installation of the GUI add-on is optional?

OK, I hope these suggestions are helpful!

[yaqwsx]

Hi! Thanks for the write-up. Let me comment on your suggestions, and I hope we can find a way to improve the documentation.

Regarding GUI - the plugin GUI indeed overwrites the currently opened board with the panel. We use Pcbnew as a "preview" of the panel. The plugin doesn't save the panel anywhere - it just renders it into the currently opened Pcbnew window so you can quickly tweak the settings and see the result. If you want to save it, you can save it via File -> Save.

At the moment, there is no portable nor fast way of opening a new Pcbnew window and controlling it. Neither can we close the current project, as far as I am aware. Therefore, we expect the user to open a blank board in Pcbnew (hence the standalone version of Pcbnew) and run the plugin from it. If you know a way of doing this, I am open to reworking the GUI; similarly, if you have a suggestion for better phrasing, let me know!

Regarding saving & loading the design: As of version 1.0.5 (current release), this is not possible. However, in the upstream version (which will become 1.1.0) this is already implemented. You can save & load panel settings in the GUI. I expect that the v1.1.0 will be released in the upcoming weeks.

And finally, yes, GUI is totally optional. KiKit is "automation" first. So its primary use case is to run in standalone in headless environment.

[yaqwsx]

Hi! Thanks for the write-up. Let me comment on your suggestions, and I hope we can find a way to improve the documentation.

Regarding GUI - the plugin GUI indeed overwrites the currently opened board with the panel. We use Pcbnew as a "preview" of the panel. The plugin doesn't save the panel anywhere - it just renders it into the currently opened Pcbnew window so you can quickly tweak the settings and see the result. If you want to save it, you can save it via File -> Save.

At the moment, there is no portable nor fast way of opening a new Pcbnew window and controlling it. Neither can we close the current project, as far as I am aware. Therefore, we expect the user to open a blank board in Pcbnew (hence the standalone version of Pcbnew) and run the plugin from it. If you know a way of doing this, I am open to reworking the GUI; similarly, if you have a suggestion for better phrasing, let me know!

Regarding saving & loading the design: As of version 1.0.5 (current release), this is not possible. However, in the upstream version (which will become 1.1.0) this is already implemented. You can save & load panel settings in the GUI. I expect that the v1.1.0 will be released in the upcoming weeks.

And finally, yes, GUI is totally optional. KiKit is "automation" first. So its primary use case is to run in standalone in headless environment.

[gwideman]

Your description fits what I (eventually) surmised from the docs page.

But again, I alert you to "Regarding GUI - the plugin GUI indeed overwrites the currently opened board with the panel." -- in using the words "replace" or "overwrites", it looks very much like you're saying that the GUI overwrites the currently open file on disk. I'm again pretty sure that you mean that the GUI does not overwrite the file on disk, but simply replaces PCBNew's in-memory content and puts in its place the panel PCB. (Of course, that still might be destructive, if the user has not saved the currently opened board since last edits.)

The coming ability for the GUI to save and load the panel settings will definitely bring the GUI's possible uses in line with users expectations of what a GUI might do, making it more a more viable everyday UI.

Regarding refinements to the GUI: at the moment it offers slots to enter each of the parameters that the user could other wise compose into command line parameters or JSON slots, so it serves the useful purpose of showing how to compose the JSON with correct syntax. However, it does not help much in understanding what the parameters actually mean or do.

It might be a lot to ask, but a significant leap forward would be to add an info-graphic pane that synchronizes with the cursor in the data entry slots. When the user clicks into a parameter slot, the graphic pane would show an image of a PCB panel with an annotation (say dimension lines or arrows to the feature) showing what aspect of the PCB panel that parameter controls. This substantially overlaps with your doc pages panelizeCli.md and examples.mdf, but brings into view the info needed for each particular parameter just as its needed. I'm not sure that the necessary info is able to be compressed sufficiently into this "synchronized info graphic" approach, but it would be great if it could!

As a side note, your development of this panelization addon provides a nice exploration and description of the kinds of panel variations that PCB designers might want and could specify for their boards, independently of whether or not they use Kicad. So it is becoming a nice educational contribution!