kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

Hi Conrad,

We are working towards removing all the UI dependencies (already the
latest state-of-the-art is way better than the 5.1 branch in this
regard).  We are also working towards a more stable Python API.

One of the goals of this work is to enable some of the features you
mentioned (automated generation of outputs, etc).


On Mon, Jul 13, 2020 at 11:06 AM Conrad Wood <launchpad@xxxxxxxxxxxxxx> wrote:
> > > 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)

https://gitlab.com/kicad/code/kicad/-/issues/3865
https://gitlab.com/kicad/code/kicad/-/issues/2151

This wish doesn't actually have much to do with code that is tied to
the UI, it is just a fairly big project that nobody has started on.

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

I'm familiar with this functionality but I don't think anyone has yet
put serious thought into it for KiCad yet (I don't think there's an
open issue tracking it, nor a spec or any kind of roadmap).

Perhaps the best way to start would be to make some more formal detail
of the requirements (in the form of a wishlist issue on GitLab) and we
can start figuring out the technical challenges.

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

The current planned approach is to ensure clean separation between the
UI and the rest of the code, and to expose a stable API via Python for
people to extend and automate KiCad with.

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

Long-term plans need buy-in from the lead developer team (and Wayne,
as project lead, is final arbiter of things where we can't reach
consensus).

This mailing list is a reasonable place to discuss things (especially
general things) before any decision is made.  Discussing specific
ideas on a GitLab issue related to the idea is also good.

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

We use roadmaps, and since the move to GitLab also the Epics feature
of that tool, to track large sets of changes that span multiple
releases.

> c) How can I help? :)

If you are interested in contributing code, my recommendation is to
start small and submit some patches for existing issues while you get
familiar with KiCad's architecture.

Understanding the current architecture is important to be able to
contribute to planning any future architecture changes.

There is a list of issues tagged "starter" that means one of the
developers thought this issue might be more approachable to someone
new to the codebase:

https://gitlab.com/kicad/code/kicad/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=starter

Hope this helps!

Best,
Jon