kicad-developers team mailing list archive

[Mark Roszko <mark.roszko@xxxxxxxxx>]

> I also think it would enable independent software developers to build
software on top of, or around kicad, further enhancing its value.

They should be contributing to KiCad first ;)
These plans for separation have been around for years, the problem is the
amount of devs is limited and their time even more so. It is an open source
volunteer effort after all.

On Wed, Jul 15, 2020 at 12:26 PM Conrad Wood <launchpad@xxxxxxxxxxxxxx>
wrote:

> I looked at the SWIG stuff some months ago (because I'm keen on Golang
> APIs). My SWIG-fu was nowhere near as good to figure out to compile
> anything but the python bindings (and even that was non-trivial IMHO)
>
> I think it would be much easier (as in trivial) if there be a clean
> split between UI (and dependencies) and non UI.
>
> If there were a library (kicad.so) with the relevant functions, then it
> would be quite trivial to create (and maintain) Bindings. The GUI ought
> to use the library as well, but ideally the library should not depend
> on any GTK of any sort.
>
> If that split were as clean as I imagine it, it would even be easy to
> create additional functionality, such as (kicad-diff.so) or (kicad-
> tools.so) which the GUI could choose to use or not. Maybe splitting out
> kicad-eeschema.so and kicad-pcbnew etc makes sense too.
>
> This would make it much easier to allow maintainers to focus on one
> area and become the "domain expert" there. Hopefully, this would also
> release some pressure on the current (lead) developers, I imagine.
>
> I also think it would enable independent software developers to build
> software on top of, or around kicad, further enhancing its value.
>
> That's another reason why I think it might be useful to think and
> document a little about the architecture and the components of future
> Kicad releases and the long-term evolution.
>
>
>
>
> On Wed, 2020-07-15 at 08:00 -0700, Seth Hillbrand wrote:
> > Our main focus is stabilizing the Python API.  If there is a
> > motivated developer who steps up to contribute and maintain (fix
> > bugs) an alternate language binding, we could consider additional
> > support in the main tree.  For right now, that is not on our list of
> > features for v6.
> > Best-
> > Seth
> >
> > Seth Hillbrand
> > Lead Developer
> > +1-530-302-5483‬
> > Davis, CA
> > www.kipro-pcb.com    info@xxxxxxxxxxxxx
> >
> >
> > On 2020-07-13 21:00, Tim Hawkins wrote:
> > > Would it be possible to consider using swig to create the Python
> > > Bindings, so that it will be easy to create bindings for other
> > > languages than just Python, Java, Kotlin or Rust would be of
> > > interest to me.
> > >
> > > On Tue, Jul 14, 2020 at 1:06 AM Jon Evans <jon@xxxxxxxxxxxxx>
> > > wrote:
> > > > 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
> > > >
> > > > _______________________________________________
> > > > Mailing list: https://launchpad.net/~kicad-developers
> > > > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> > > > Unsubscribe : https://launchpad.net/~kicad-developers
> > > > More help   : https://help.launchpad.net/ListHelp
> > >
> > > _______________________________________________
> > > Mailing list: https://launchpad.net/~kicad-developers
> > > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> > > Unsubscribe : https://launchpad.net/~kicad-developers
> > > More help   : https://help.launchpad.net/ListHelp
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>


-- 
Mark