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
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
