kicad-developers team mailing list archive

[Conrad Wood <launchpad@xxxxxxxxxxxxxx>]

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
> now
> scripting can only control a GUI instance. This is kind of annoying
> for
> 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-
> dimensional
> while files are one-dimensional strings of bytes. Anything that is
> able
> to generate meaningful diffs would need to fully understand the
> files,
> 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
> a
> notification system than we currently have (basically, we know to
> update
> *the* view when data changes, but we'd need to track multiple views
> on
> 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
this out. 

I guess what I am really asking, is, 

a) what is the decision making process for KiCad-Dev for such long-term 
changes? 

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? :)