kicad-developers team mailing list archive

[Ian McInerney <Ian.S.McInerney@xxxxxxxx>]

The core features of KiCad do not rely on GTK, or any specific toolkit
other than wxWidgets currently. GTK is only required if you want to use
KiCad on Linux machines, and it will use the native (Win32 and Appkit)
frameworks on the other operating systems [1]. The core code does have a
dependency on the core wxWidgets libraries for things like file IO though,
but that dependency is not concerning for this work.

KiCad is a complicated application, with a long history. Design changes
that are fundamental to the core code take time to implement and cannot be
done overnight. Couple that with the fact that the current set of active
developers is small (I believe we have ~10 lead developers, and around 5-10
other regular contributors), large changes like that will take a developer
away from other features that users want. Pausing KiCad releases for a very
long time to do the refactor of the backend code will not be helpful to
users who want features added during that release cycle and to use those
features in the near future. As such, we incrementally do it as we work in
areas, as it is needed for other new features, and as developers have time.
The current developer viewpoint is that we don't add new features or code
that will make this separation more difficult to achieve in the future, but
try to either introduce more separation or keep it at the same level with
new features. During each development cycle, small projects are done in the
beginning to introduce more separation, and we are trying to work towards
the point where that final separation can be achieved during a release
cycle, but it isn't going to be in version 6.

I will echo what has been said before: to get an understanding of the
current state of the KiCad codebase and what it will take to do a refactor
that accomplishes what you are suggesting, please look through the code and
experiment with it (fixing issues and implementing small new features is a
good way to do that). I have been in the codebase for around a year at this
point, and even I still don't understand some aspects of it.

-Ian

[1] Technically you could use any of the ports of wx on the platforms they
support (e.g. wxGTK on windows), but we only will provide support for the
native port running on the machine.



On Wed, Jul 15, 2020 at 5: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
>