kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx>]

On Thu, Oct 29, 2015 at 10:06 AM, Mário Luzeiro <mrluzeiro@xxxxx> wrote:

> Hi Cirilo, all,
>
> Related with the plugins and APIs, I have in mind some open questions
> related with:
>
> - will it be possible to build the plugins without using kicad source
> code? Maybe for some type of plugins it will be easy to have an API, but
> for things related with kicad, it can be an huge library or dependencies.
>

The plugins can be built without the kicad source; all you need are the
correct headers to implement the API. The API is inevitable ( or APIs - in
my notes there are plans for API3D
which is related to 3D intermediate format, APIEXP for export, APIIMP for
import, and if
the renderer is also a plugin then API3D or similar ). Without the API we
are forced to use
static linking to implement many things. The API is not a bad thing; it
gives a more structured
interface which can be exploited later to provide more external tools.


> - will some plugins be embedded in kicad sources by default? or will be
> packaged in the installers?
>

All the plugins which I plan to develop will be in the kicad source but
there is nothing to
prevent people from creating their own out-of-tree plugins. As far as
packaging plugins
go, I see that as an issue for package maintainers and not for developers.
A typical setup
which I would expect would package the VRML1/2, X3D, and IDF plugins, and
maybe the
IGES plugin. If a STEP plugin is developed which depends on OCE then I
would expect
that to be an optional compilation and to be in an optional package
installer even if the
source code is in the kicad tree.


> - how kicad project will adopt / manage / integrate that plugins?
>
>
I'm still thinking about this. It is clear that we need a number of plugins
and APIs and
the headers for all of these should be in a location where it's easily
accessed by
anyone who wants to build a plugin. The plugin integration of course will
be magic. :)
Behavior will vary depending on the plugin, for example:

a. 3D plugin:  the Cache Manager searches for these and loads them as
required.
The Cache Manager essentially hides these plugins from the rest of kicad -
any
dynamic changes to various GUI widgets happens through interaction with the
Cache Manager. The Cache Manager needs some hints from elsewhere in the
program about unloading the plugins or flushing the cache. For example, the
3D viewer will ask to load various models and the Manager may need to load a
plugin. The 3D viewer might ask the Manager to close all plugins on exit or
maybe
after finishing the loading of components; the 3D viewer will probably not
want to
ask the Manager to flush the cache.

b. Export plugin: these will require a class inside pcbnew to manage these
plugins.
The export plugin manager will load plugins at startup (or you can always
add a
menu item to refresh at runtime) and dynamically add items to the
File->Export
menu. All plugins will remain closed until Export is invoked, then the
appropriate
plugin will be loaded, the export function will be run, and the plugin will
be unloaded.
So in this case the lifetime of the plugin in memory is much better defined
than in
the case of the 3D plugin.

As for third-party plugins, the usual rules apply: since they are not in
our tree and
we cannot control them (or necessarily even see the source) we cannot
recommend
them. Users install such things at their own risk.

- Cirilo


> Mario
>
> ________________________________________
> From: Kicad-developers [kicad-developers-bounces+mrluzeiro=
> ua.pt@xxxxxxxxxxxxxxxxxxx] on behalf of Cirilo Bernardo [
> cirilo.bernardo@xxxxxxxxx]
> Sent: 28 October 2015 00:32
> To: KiCad Developers
> Subject: [Kicad-developers] update on 3D refactor
>
> Thanks to nickoe I'm finally able to build on MSWin and was able to
> get the dynamic plugins working on that platform. With some help on
> the kicad IRC channel I was able to make changes and verify that
> dynamic plugins work on OSX as well. (On MSWin I will need to do
> some more work - the file selector visuals are unbelievably ugly at the
> moment, but this really has nothing to do with dynamic plugins.)
>
> Now that I know how to make dynamic plugins work I should be able
> to (1) finish the implementation of 3D model loading via dynamic
> plugins, and (2) create a dynamic plugin scheme for Export functions
> so I can finally implement an IGES exporter. My intention with the
> Export plugins is to make it possible to implement a dynamic Export
> menu and to load exporter code as required; the implementation
> will make it possible to add more export options without touching any
> KiCad source files at all. In principle dynamic plugins can also be
> implemented for Importers but I believe the Export plugin job will keep
> me busy for a long time since an API must be developed to interact
> with KiCad and this will not be a trivial task.
>
> I'll finish work on (1) first of course so we can take advantage of Mario's
> new renderer and have 3D previews of model files as we browse them.
>
> - Cirilo
>
>