With my workflow I often find myself working on multiple projects with multiple PCBs each.
This leads to me often having to have multiple instances of KiCAD open, manually locating the projects on the disk, etc.
My idea for an addition to KiCAD is a workspace model to organise multiple projects into a logical unit.
The project would look as follows:
Workspace file in JSON format
Separate workspace management window to launch KiCAD/eeschema/pcbnew instances
(maybe) Synchronisation between project libraries through management on the workspace level
Ultimately my questions are:
Are people interested in this at all?
If I do start development on this, how do I keep the code and project as âKiCAD-yâ as possible?
Are there already similar projects I havenât yet seen?
Are there additional features that might be useful?
Examples of how the workspace file and management window could look:
Basically yes, although I personally think that a library manager (real manager, not just the editor + some management as it is now) would be more important.
As far as I can see, the configuration file would need to be only a list of project files with the whole paths. The description and âhuman readableâ name could be integrated to the .kicad_pro file format. This would require reading all files to form the final list, but IMO itâs not good to have extra information about a project outside that project itself.
The UI view could be embedded into the current project manager, for example as a tab in the view which currently has the subapplications.
Ooof, this is a more complicated topic that can be answered on the forum where the developers like me do not really get into things like this. The correct way is to write up a issue describing a feature set like this
I will say, we do have plans in the future to eliminate the subapplications and move to a MDI interface ala altium which will probably affect how âworkspacesâ work because there will be no more launcher.
Also workspaces should be optional. I or other users should not be stuck having to now manually unload projects from a workspace just because I previously loaded a project.
To provide some perspective, I created this post just to get some opinions to gauge if it is worth putting real development effort into the idea.
It was initially thought of as an addition to KiCad without having to interfere with the existing codebase a lot, though if tighter integration is of interest, I would be happy to work on that.
As to workspaces being optional, I could see an approach where you explicitly have to add a project to the current workspace after loading it (in addition to the route of adding a project to the workspace without having to load it) in order to preserve the current behaviour.
@marekr Following your advice I will spend some time writing an issue with a more thorough feature set description.
If you intend to make a separate tool altogether, then thatâs fine, no need for us to get involved
However, if you need something in KiCad added, then that involves discussion. If your desire is something that starts separate but ends up packaged with KiCad, then that discussion also applies.
I do have a few projects that include a âcontrolâ PCB, as well as a few sub-PCBs that fan out from that using cables or headers, or whatever. I think what you are describing is a natural direction for KiCad to go, as it matures even more. Currently, Iâm doing the obvious thing of having an overall folder with a bunch of KiCad projects in it for each different PCB. This isnât a terrible way to work, but as you say, slightly cumbersome sometimes. If a workspaces application existed, and it worked really well, I would use it occasionally.
One minor suggestion though: Instead of using JSON, it might be a good idea to use S-Expressions, in order to keep the file formats consistent with what KiCad uses. Theyâre pretty straightforward to turn into Python lists, not really any harder than JSON.
My understanding of the problem statement is that the data file portion of this project is more like a hierarchical project file than a config. Something like a .kicad_pro file, but a level above. KiCad project files, schematic files, and PCB files are all S-Expressions.
As to readability, I donât find this particularly challenging:
Thatâs because itâs been pretty printed and there are naming conventions on the elements. In its bare form S-expressions are only nested lists while JSON is closer to programing language structures.
But it depends on what use the file will play in the proposed project if it comes about. Since JSON is already supported, it can also be considered.
Any complex nested heterogenous data structure is beyond human ability to parse, so we delegate that task to libraries. Otherwise itâs FORTRAN and everything is an array again.
Except one is widely accepted in the industry and has gazillions of standard libraries to deal with as well as meta libraries like schemas etc. and another is a reinvented bicycle that everyone has to hand code after spending a moment pondering âwhy, just whyâ.
Does it have to be a separate structure / level?
What if kicad_pro files could contain other projects too hierarchially, in addition to schematic and pcb?
Then you could have a top level project file for the âmotherboardâ (as an example), and this would then also contain the information on what projects are the âdaughter boardsâ.
I think the JSON/S-Expression discussion isnât super relevant to this post, though to explain my choice of JSON:
The project files are already JSON
KiCad provides the rather convenient seeming JSON_SETTINGS class.
@hmk: I have also thought about that. From my quick reading over the codebase it seems relatively straight forward to just add another config path containing sub-projects to the project configuration file, thought at this point it is not entirely clear to me how project specific variables like KIPRJMOD would interact between root and child projects.
There are honestly good reasons for either approach, at this point the best idea for me is probably to do a small write up of different ideas and approaches as there seems to be some interest in the basic idea.
Personally I think there would be more important issues to tackle first⌠you can just set up a folder structure in Windows to mimic the Workspace managerâŚ
And making KiCad support opening more windows for PcbNew and EESchema (at least on Mac it only like to open one at a time) would solve the core issue of working with multiple documents, without needing a Workspace manager.