Re: [Kicad-developers] Kicad 6 API
Modularization is a key part to large-scale refactoring, if you have system that can't be subdivided then that a good indicator that you have an architectural problem. One of the best refactoring patterns for large systems is the "Strangler fig pattern", where you split out a unit of functionality as a seperate module and refactor that. In this case I'm speaking of modules nothing the kicad sense of its bunch of seperate apps, but in the sense of a lot of small subunits, somebody spoke above of a kicad.so library, but that is in itself too large a chunk and things need to be a lot smaller than that. I'm a 40 year veteran coder, c, c++, php, java, kotlin, and c#/dotnet core. I have not been very active in OSS, maybe it's time that changed, and kicad sounds like a good project to engage with, as it would engage with my interests (PCBs, CNC, 3d printers etc, personal fabrication). I use fedora Linux everywhere, I have all the tooling required. Where can I find a good guide for getting started with the project? On Thu, Jul 16, 2020, 07:10 Wayne Stambaugh wrote: > Hi Conrad, > > On 7/15/20 3:51 PM, Conrad Wood wrote: > > On Wed, 2020-07-15 at 13:53 -0400, Mark Roszko wrote: > >>> 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. > > > > Isn't that a bit of a chicken-and-egg situation? > > Not necessarily. Refactoring can be done incrementally over long > periods of time. It doesn't have to be an all or nothing effort. This > is pretty much how the Linux kernel development happens. > > > > > I mean, it's fairly hard to start contributing to KiCad due to its > > complexity. (at least that is my impression - but then I might just be > > stupid :) ) > > IMHO, splitting it up would lower the entry barrier to new-comers. > > EDA applications are by their nature complex so I don't know how > splitting up complex code would lower the barrier to entry. I'm not > suggesting that the KiCad code base couldn't be vastly improved but I > cannot see how that will lower the barrier to entry for new developers. > > > > > I'd be more than happy to contribute, but clearly I can't just "split > > out bits into a library" on my own w/o discussion and consensus. That > > _has_ to be a team effort, right? > > Any changes to the code structure would require discussion and consensus > with the lead development team. My guess any discussion that you could > think of has already been discussed more than once. It's generally a > good idea to check the developer list mailing archives for previous > discussions so we don't have to rehash the same discussion. > > > > > I understand, that there never is "The Right Time" to do something like > > it and I consider it very important not to add any extra workload on > > already stretched people. > > > > Rather, with starting this discussion I hope to contribute with my > > limited means, specifically, finding a means to spread the workload a > > bit more evenly, and at some point, I might be able to directly > > contribute as well. > > I will reiterate Seth's comments about starting small. It really is the > most sensible path forward to becoming a member of the development team. > > Cheers, > > Wayne > > > > > > Also, for the sake of clarity, when I mentioned about on top of or > > "around kicad" I was very much thinking of more open-source software, > > not closed systems! Thus adding to the functionality of KiCad. > > > > Conrad > > > > > > > > ___ > > Mailing list: https://launchpad.net/~kicad-developers > > Post to : kicad-developers@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~kicad-developers > > More help : https://help.launchpad.net/ListHelp > > > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Kicad 6 API
Hi Conrad, On 7/15/20 3:51 PM, Conrad Wood wrote: > On Wed, 2020-07-15 at 13:53 -0400, Mark Roszko wrote: >>> 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. > > Isn't that a bit of a chicken-and-egg situation? Not necessarily. Refactoring can be done incrementally over long periods of time. It doesn't have to be an all or nothing effort. This is pretty much how the Linux kernel development happens. > > I mean, it's fairly hard to start contributing to KiCad due to its > complexity. (at least that is my impression - but then I might just be > stupid :) ) > IMHO, splitting it up would lower the entry barrier to new-comers. EDA applications are by their nature complex so I don't know how splitting up complex code would lower the barrier to entry. I'm not suggesting that the KiCad code base couldn't be vastly improved but I cannot see how that will lower the barrier to entry for new developers. > > I'd be more than happy to contribute, but clearly I can't just "split > out bits into a library" on my own w/o discussion and consensus. That > _has_ to be a team effort, right? Any changes to the code structure would require discussion and consensus with the lead development team. My guess any discussion that you could think of has already been discussed more than once. It's generally a good idea to check the developer list mailing archives for previous discussions so we don't have to rehash the same discussion. > > I understand, that there never is "The Right Time" to do something like > it and I consider it very important not to add any extra workload on > already stretched people. > > Rather, with starting this discussion I hope to contribute with my > limited means, specifically, finding a means to spread the workload a > bit more evenly, and at some point, I might be able to directly > contribute as well. I will reiterate Seth's comments about starting small. It really is the most sensible path forward to becoming a member of the development team. Cheers, Wayne > > Also, for the sake of clarity, when I mentioned about on top of or > "around kicad" I was very much thinking of more open-source software, > not closed systems! Thus adding to the functionality of KiCad. > > Conrad > > > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Kicad 6 API
On 2020-07-15 12:51, Conrad Wood wrote: On Wed, 2020-07-15 at 13:53 -0400, Mark Roszko wrote: 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. Isn't that a bit of a chicken-and-egg situation? I mean, it's fairly hard to start contributing to KiCad due to its complexity. (at least that is my impression - but then I might just be stupid :) ) IMHO, splitting it up would lower the entry barrier to new-comers. I'd be more than happy to contribute, but clearly I can't just "split out bits into a library" on my own w/o discussion and consensus. That _has_ to be a team effort, right? The chicken/egg analogy is spot on. Despite the complexity, we have both chickens and eggs. This happens by changing small things at a time. If you would like to contribute to KiCad, you should start small. Pick an area of the program that you are interested in and find the bug reports relating to it. Then figure out why it is broken and write a patch to fix it. After you do a few of these and they are accepted, you will gain familiarity with how the codebase is meant to work. At that point, you might look at some of the wishlist items in the tracker that relate to the area you have picked. This will ease you into how the system works and ensures that your first patches are small enough that you can learn how the team works and what we expect in the code contributions. We are never going to support folks doing fundamental/structural work who aren't established contributors. It is counterproductive to the success of the project. I hope that you will choose to begin contributing. We will work with you to help you get started. The smaller the first issue you tackle, the easier it will be for you. We tag issues in our database with the label "starter" to identify those issues we think newcomers will have the easiest time addressing. Best- Seth Seth Hillbrand KiCad Services Corporation https://www.kipro-pcb.com +1 530 302 5483 | +1 212 603 9372 ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Kicad 6 API
On Wed, 2020-07-15 at 13:53 -0400, Mark Roszko wrote: > > 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. Isn't that a bit of a chicken-and-egg situation? I mean, it's fairly hard to start contributing to KiCad due to its complexity. (at least that is my impression - but then I might just be stupid :) ) IMHO, splitting it up would lower the entry barrier to new-comers. I'd be more than happy to contribute, but clearly I can't just "split out bits into a library" on my own w/o discussion and consensus. That _has_ to be a team effort, right? I understand, that there never is "The Right Time" to do something like it and I consider it very important not to add any extra workload on already stretched people. Rather, with starting this discussion I hope to contribute with my limited means, specifically, finding a means to spread the workload a bit more evenly, and at some point, I might be able to directly contribute as well. Also, for the sake of clarity, when I mentioned about on top of or "around kicad" I was very much thinking of more open-source software, not closed systems! Thus adding to the functionality of KiCad. Conrad ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Kicad 6 API
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 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.comi...@kipro-pcb.com > > > > > > 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 > > > 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).
Re: [Kicad-developers] Kicad 6 API
Also, the separation of UI from the rest of code, like any big refactoring, is not something that is practical to first plan in its entirety and then execute all at once, as other software teams have learned many times[1]. It is a goal that we proceed towards over time. It is not in the interest of any KiCad user if the development team stops implementing any new features or bugfixes for a year or more just to accomplish some massive refactoring. So, we do the refactoring along with introducing new features, and gradually. We already have a number of domain experts who work on KiCad, and we welcome others to get involved! The best way to understand KiCad's architecture and the direction it is moving in is to start making code contributions and follow along with the contributions from others. [1] https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ -Jon On Wed, Jul 15, 2020 at 2:04 PM Mark Roszko wrote: > > > 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 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.comi...@kipro-pcb.com >> > >> > >> > 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 >> > > 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 < >> > > > launch...@conradwood.net> 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 >> > > >
Re: [Kicad-developers] Kicad 6 API
> 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 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.comi...@kipro-pcb.com > > > > > > 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 > > > 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 < > > > > launch...@conradwood.net> 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
Re: [Kicad-developers] Kicad 6 API
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.comi...@kipro-pcb.com > > > 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 > > 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 < > > > launch...@conradwood.net> 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
Re: [Kicad-developers] Kicad 6 API
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 KiCad Services Corporation Seth Hillbrand Lead Developer +1-530-302-5483 [1] Davis, CA www.kipro-pcb.com [2]i...@kipro-pcb.com https://twitter.com/KiProEDA [3] https://www.linkedin.com/company/kicad [4] 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 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 >> 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=%E2%9C%93=opened_name[]=starter >> >> Hope this helps! >> >> Best, >> Jon >> >>
