On 7/16/20 12:13 AM, Tim Hawkins wrote:
> 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.
Parts of KiCad are very modular. Other parts, not so much. There is
still plenty
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
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
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
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
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
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
> 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
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
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
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
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
On Mon, 2020-07-13 at 15:09 +0200, Simon Richter wrote:
> Hi Conrad,
>
> On 13.07.20 14:48, Conrad Wood wrote:
>
> > I am keen on generating the outputs for manufacturing and
> > documentation
> > (e.g. circuit diagram pdfs, rendered 3d-view of pcb) as part of a
> > git
> > hook.
>
> There is
Hi Conrad,
On 13.07.20 14:48, Conrad Wood wrote:
> I am keen on generating the outputs for manufacturing and documentation
> (e.g. circuit diagram pdfs, rendered 3d-view of pcb) as part of a git
> hook.
There is still some UI code inside the data representation, so for now
scripting can only
On Thu, 2020-07-09 at 15:18 +0200, Nick Østergaard wrote:
> Are you talking about the python scripting API, or what is your
> intention?
I am keen on aiding some of the processes in PCB design & manufacturing
using KiCad as the tool to provide the design of the pcb. After design,
I found that
Are you talking about the python scripting API, or what is your intention?
tor. 9. jul. 2020 14.20 skrev Conrad Wood :
> Hi,
>
> I have a keen interest on APIs for Kicad6. I wonder if there are any
> documents describing the intented architecture and APIs of Kicad6 yet?
> If so could you give
Hi,
I have a keen interest on APIs for Kicad6. I wonder if there are any
documents describing the intented architecture and APIs of Kicad6 yet?
If so could you give me a pointer where?
If not, is there any interest in me starting a google doc and begin to
propose something like it?
Conrad
17 matches
Mail list logo
