KiCAD Workspaces: Would people be interested in this?

[dtreffenstaedt]

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:

Workspace file

default_workspace.kicad_wrk
{
    "projects": {
        "proj1": {
            "name": "Example",
            "description": "This is a description",
            "path": "./relative/path/test_project/",
            "project_file": "test_project.kicad_pro"
        },
        "proj2": {
            "name": "Example 2",
            "description": "This is a description",
            "path": "/home/example/absolute/path/test_project/",
            "project_file": "test_project.kicad_pro"
        }
    },
    "settings": {
        "name": "Default Workspace",
        "current_project": "proj1"
    }
}

Workspace management window

[eelik]

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.

[marekr]

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

Issues · KiCad / KiCad Source Code / kicad · GitLab

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.

[dtreffenstaedt]

Thank you both for your feedback.

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.

[marekr]

@dtreffenstaedt

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.

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.

[craftyjon]

@eelik

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 know, nobody has really described this wish in any detail.

[Jarrett]

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.

[retiredfeline]

@Jarrett

Instead of using JSON, it might be a good idea to use S-Expressions

KiCad 6 already uses JSON for the config settings. JSON is easier for a human to read and edit in the last resort.

[Jarrett]

@retiredfeline

KiCad 6 already uses JSON for the config settings. JSON is easier for a human to read and edit in the last resort.

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:

[retiredfeline]

@Jarrett

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.

[marekr]

@retiredfeline

In its bare form S-expressions are only nested lists while JSON is closer to programing language structures.

Eh, they are both the same insanity to parse. Sexpressions are just a glorified alternate form of XML. Both can represent programming object model.

[retiredfeline]

@marekr

Eh, they are both the same insanity to parse.

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.

[qu1ck]

@marekr

Eh, they are both the same insanity to parse.

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”.

[craftyjon]

@Jarrett

Something like a .kicad_pro file, but a level above. KiCad project files, schematic files, and PCB files are all S-Expressions.

KiCad project files are JSON.

[hmk]

@craftyjon

@Jarrett

Something like a .kicad_pro file, but a level above.

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”.

[dtreffenstaedt]

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.