kicad-developers team mailing list archive
Mailing list archive
Re: Kicad 6 API
On Mon, 2020-07-13 at 15:09 +0200, Simon Richter wrote:
> Hi Conrad,
> On 13.07.20 14:48, Conrad Wood wrote:
> > I am keen on generating the outputs for manufacturing and
> > documentation
> > (e.g. circuit diagram pdfs, rendered 3d-view of pcb) as part of a
> > git
> > hook.
> There is still some UI code inside the data representation, so for
> scripting can only control a GUI instance. This is kind of annoying
> git hooks as you need to set up a fake display server.
Exactly. I feel understood and I am pleased that this is a "known"
annoyance rather than an "unknown" one :)
> > I've seen various 'hacks' out there to provide a graphical 'diff'.
> > I
> > would like to see the API either provide means to do a diff on two
> > commits of the same repository, graphical or otherwise, in such a
> > way
> > that it can be integrated into a web-based process.
> > (with "diff" I mean a method to see where and what changes were
> > made in
> > two versions by a person not trained to do PCB design. - this is
> > mostly
> > to review changes and spot unintended modifications)
> diff/merge is non-trivial, because PCB structures are three-
> while files are one-dimensional strings of bytes. Anything that is
> to generate meaningful diffs would need to fully understand the
> not just look for similarities.
Indeed. That's why I think much of the parsing and 'understanding' of
the files should be moved out of the GUI and into a library. Then we
can have an API for it and can start building on top of it.
> > On bigger/complex boards, there are often 'sections' which are
> > handled
> > by exports. for example, radio vs memory/cpu vs powersupply. It
> > would
> > absolutely awesome if we can progress KiCad to support such teams.
> > In
> > my mind, I am thinking of a KiCad server which serves clients and
> > sections can be 'locked' and worked on simultaneously.
> > Simultaneously I
> > mean, with changes being propagated to each KiCad Client in real-
> > time.
> That is partially a function of diff/merge, and also requires more of
> notification system than we currently have (basically, we know to
> *the* view when data changes, but we'd need to track multiple views
> the data and add a way for data modifications to fail because of
> conflicts -- plus UI presentation for that.
> That would require a lot of changes to internals.
I am quite aware that this is a lot of changes. I don't suggest that we
do everything at once. What I'd like to see though, is that there is a
long term view of where we want to take APIs and the GUI/Library split
(currently not even certain if that is the planned approach).
I am no expert at the KiCad code, but when I did look if I can add such
APIs, it became clear that there is a lot of work to do in splitting
I guess what I am really asking, is,
a) what is the decision making process for KiCad-Dev for such long-term
b) how does KiCad-Dev deal with large-ish changes that may span
multiple releases or reach further in the future than, say, a feature
request or a bug report?
c) How can I help? :)