On 11/27/19 1:19 AM, Eeli Kaikkonen wrote:
Feel free to contact me through email or otherwise. Although I'm not
really a python developer any more than a C++ developer (I have done
some of both), in this context I'm personally more interested in
getting the python part of KiCad forward.
On 11/27/19 12:15 AM, mitjan696-ubu...@yahoo.co.uk wrote:
Hi Seth,
This does sound like an invitation. I've written a number of action
plugins [1] and would be glad to help with KiCad main code, but my C++
skills are nonexistent (I do know a bit of C though, so the basic
syntax should not be
ke 27. marrask. 2019 klo 1.51 Seth Hillbrand (s...@kipro-pcb.com) kirjoitti:
> After the initial
> ideas and implementation are documented, it will go to the lead
> developers first to ensure everyone agrees with the plan and course of
> action. After that, it will be published on the list for
Hi Seth,
This does sound like an invitation. I've written a number of action plugins [1]
and would be glad to help with KiCad main code, but my C++ skills are
nonexistent (I do know a bit of C though, so the basic syntax should not be an
issue). I've never built KiCad from source and I am
On 2019-11-26 14:40, Eeli Kaikkonen wrote:
ti 26. marrask. 2019 klo 22.23 Seth Hillbrand (s...@kipro-pcb.com)
kirjoitti:
We need to start with the API definition and file format changes. The
API definition should include end points and returns. The file format
changes should include the
ti 26. marrask. 2019 klo 22.23 Seth Hillbrand (s...@kipro-pcb.com)
kirjoitti:
>
> We need to start with the API definition and file format changes. The
> API definition should include end points and returns. The file format
> changes should include the files and specific configuration lines
>
I think the differences expressed are about problems in communication, not
differences in actual opinions. I agree with myself (obviously), with what
Andrew said and with Ian. We are just talking past each other, about
different things.
Me said (meant): the content manager should be generic
We should not limit the end points available to users to be only the KiCad
systems we decide, and also should not constrain plugins to be open source.
Doing this would constrain independent companies from developing plugins to
interface KiCad with their systems if they so choose (for instance, if
API definition and file formats are second step. We need to agree on
supported use cases, high level data flows, systems pieces involved.
Thing with public infra is that it's easy to move it to private infra but
not the other way around. So it's best to design as much of the system as
possible to
On 2019-11-25 17:46, Andrew Lutsenko wrote:
Hi Seth,
Yes, I planned to write up my design in google doc and open it to
comments. I think that works best for public discussion, even though it
requires having a google account.
Design I'm thinking about requires 0 custom backend work. It will
ti 26. marrask. 2019 klo 11.27 Nick Østergaard (oe.n...@gmail.com)
kirjoitti:
> I don't know if you use freecad, if you do you probably used the addon
> manager. It is quite helpful in installing python plugins.
>
> It is probably worth reviewing how it works conceptually.
>
Yes, I know about
OK, I refreshed my memory. I have a group in github (not gitlab):
https://github.com/kc-plugin-publishers. You can check out there what I
have written. There are three things: the manager script (plugin), example
dummy plugins to be installed, and the description files (.plugininfo
files). Now
I'm in a hurry right now, so I just give few points. You can find some
discussions in the forum (I'll find them later). What I learned when I did
some coding is this:
- Ideal content manager is a separate backend and frontend and reusable for
other projects, too.
- It's really general purpose and
That's good to know.
For minimal implementation it will not be required but it can be used for
telemetry, user ratings and things like that.
I'll talk about it more in the doc.
I'm assuming it's easy to expose some service wrapped in a container via
endpoint like kicad-pcb.org/api/v1/ratings or
>always add custom backend system later to complement free infra.
We do have free infrastructure that can run backend code at CERN. Just
needs to package up in a docker container and run as non-root inside the
container. Assuming also it's not some resource hog of a system that eats
the entire
Hi Seth,
Yes, I planned to write up my design in google doc and open it to comments.
I think that works best for public discussion, even though it requires
having a google account.
Design I'm thinking about requires 0 custom backend work. It will rely
entirely on publicly available infra such as
On 11/25/19 3:21 PM, Andrew Lutsenko wrote:
Hi all,
Is anyone currently working on some sort of plugin manager or 3rd
party library manager?
https://bugs.launchpad.net/kicad/+bug/1823733
I have some ideas that I want to write down in a form of high level
design document and share with the
That’s been a topic near to my heart for some time, but I’ve done nearly
nothing toward implementing it. I’d be very interested in being involved in
discussions of possible shapes it could take.
-Brian H
> On Nov 25, 2019, at 6:21 PM, Andrew Lutsenko wrote:
>
>
> Hi all,
>
> Is anyone
18 matches
Mail list logo
