kicad-developers team mailing list archive

[Tomasz Wlostowski <tomasz.wlostowski@xxxxxxx>]

On 09/19/2013 04:29 PM, Miguel Angel wrote:
> Ok, summarizing all the feedback:
>
> I'd defer this blueprint proposal, and switch it into something like:
>
> * Making a generic system wide plugin load system,
>   (load/unload/reload/enumerate/instantiate). Supporting statically
> loaded C++ plugins, and dynamically loaded python plugins.
>
> KICAD_PLUGIN
> /|\
> [PCBNEW_PLUGIN]
> /|\
>   |-- CONTEXTMENU_PLUGIN
>   |-- HOTKEY_PLUGIN
>   |--TOOLBAR_PLUGIN
>   |--
>
> * Make the C++<-->Python facade for those classes (one by one in
> separate implementations, and see how they work, so we can refine the
> implementation before we implement the next)
>
> * Make a contextmenu example (component alignment: horizontal/vertical)
Miguel,

The GUI-related plugins depend on how the UI/Tool frameworks will look 
like in the end. They need to be clarified before plugin interfaces are 
defined - but we can surely add context menu/toolbar/hotkey plugins 
anytime in the future.

My 5 cents for the plugin type list:
- S3D_MODEL_PLUGIN for loading VRML/STEP/IGES,
- APP_PLUGIN: an embeddable instance of a kicad application. In far 
future, it may become possible to put apps in tabs, embed them in a 
common shell application, etc.

Tom