kicad-developers team mailing list archive

[Eeli Kaikkonen <eeli.kaikkonen@xxxxxxxxx>]

On Wed, Jul 1, 2020 at 10:12 AM mitjan696-ubuntu@xxxxxxxxxxx
<mitjan696-ubuntu@xxxxxxxxxxx> wrote:
>
> While I like the idea of hooks I think there are a couple of things that should be implemented before and they should enable part of the workflow that you envision.
>
> To be specific, implementing action plugin interface in Project manager. Once this is in place a lot of hook actions could be implemented semi-automatic as an action plugins.

I have many times wondered why plugins can't be run from the project
manager. There's even no need to add any API; it would be enough if an
action plugin could be defined as "generic", not pcbnew specific, and
would be visible in the Tools menu of the project manager. There are
many tasks which don't need to use KiCad python API.

Anyways, I don't think that a better API is a prerequisite for the
hook system. There are do difference between the current plugins and
the envisioned hooks:

1) Hooks don't need to use KiCad API. Many tasks could be done with
the standard python libraries, for example string manipulation and
file system manipulation. The hook call could give the necessary data
as arguments and the function could return a string or a string list
or numerical value. A hook could of course be also more generic
without arguments, for example when it manipulates the project
folders. And the full KiCad python API would of course be available if
needed.

2) Calling hooks is "event based", while calling an action script is
done explicitly by the user. Some hook use cases could be replaced by
a better action script system (namely implementing free hotkey
assignment to call action scripts so that e.g. Save could be replaced
by an action script which then calls Save), but not all (like the
window title example mentioned in a previous post).

Eeli Kaikkonen