kicad-developers team mailing list archive

[Andrew Lutsenko <anlutsenko@xxxxxxxxx>]

Plugin manager is in the works:
https://gitlab.com/kicad/code/kicad/-/issues/2242
There will be some progress over the long weekend.

On Tue, Jun 30, 2020 at 3:06 PM Nick Østergaard <oe.nick@xxxxxxxxx> wrote:

> I like the sound of this idea, it could definitely help the workflow
> for a lot of people.
>
> What may be related to this is some properly "plugin" manager such
> that it is easier to bundle some script and have some script installed
> external, similar to the freecad addon manager.
>
> I don't remember if anyone is seriously working on that, I sorta
> expect that to be on hold unstill eeschema gets scripting support.
>
> On Tue, 30 Jun 2020 at 21:43, Eeli Kaikkonen <eeli.kaikkonen@xxxxxxxxx>
> wrote:
> >
> > On Tue, Jun 30, 2020 at 9:17 PM Mark Roszko <mark.roszko@xxxxxxxxx>
> wrote:
> >>
> >> While more extensibility is great. I can only say expecting the user to
> use python exclusively for adding the new behavior like for issue #2339 is
> very crude.
> >
> >
> > I'm not saying any possible feature which can be replaced with a script
> should be replaced. It must be decided case by case. I don't even say that
> these examples are something where an internal feature should be replaced
> with a hook. They are just possible examples to show what could be
> possible. Just think about it this way:
> >
> > 1. Which one is better, just let the users wait for the feature to be
> implemented, or add a hook which makes it possible to implement it right
> away in a simple way in a script and then let the users wait for it to be
> implemented in KiCad proper later?
> >
> > 2. Each hook makes it possible to add any imaginable functionality, not
> just one feature wish.
> >
> > 3. Adding a hook doesn't take anything away, it just adds possibilities.
> >
> > 4. Any developer is still free to implement anything  in C++. Like now
> they are free to implement a functionality which has existed only in an
> action script before.
> >
> > 5. Adding a hook doesn't change the UI or the behavior in any way. They
> wouldn't cause any bugs if the backend for the hook system is good. Hooks
> could be added even for bugfix releases. It may be much better than waiting
> for one or two years for the next feature release.
> >
> >
> >>
> >> Not everyone is a programmer
> >
> >
> > Sure. But big problems with scripting have been 1) the unstable API and
> 2) the lack of asset infrastructure. Both are being worked on. When KiCad
> scripting gets more traction and the scripts are easier to share and
> install, not everyone needs to be a programmer and still can easily benefit
> from the work from others. The potential number of python developers for
> simple scripts like string  handling and generic file manipulation is
> certainly larger than the amount of potential C++ developers.
> >
> > And if we take that #2339 as an example, it would require a real GUI in
> KiCad proper (because it would need a way to manipulate the list of
> folders). A python script would be one a couple of python functions and a
> list of text strings. If  someone writes the script, anyone can change the
> list of strings, there's no need to be a programmer to change the names of
> the folders. So, which one would be the better option: 1) add a simple hook
> to make it possible and implement the GUI later, or 2) not make it possible
> until someone implements the GUI?
> >
> > Eeli Kaikkonen
> > _______________________________________________
> > 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
>