kicad-developers team mailing list archive

[Seth Hillbrand <seth@xxxxxxxxxxxxx>]

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]    info@xxxxxxxxxxxxx

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

Links:
------
[1] tel:+12126039372
[2] https://www.kipro-pcb.com/
[3] https://twitter.com/KiProEDA
[4] https://www.linkedin.com/company/kicad