kicad-developers team mailing list archive

[Miguel Angel <miguelangel@xxxxxx>]

2013/9/19 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.
>
>
I don't agree on this, my intention is to make them totally un-coupled to
the UI itself.

*hotkey:*

The simplest hotkey plugin only needs to provide a function to tell which
default hotkey does he want to hook on, and some kind of identifier.

Then another function to receive the hotkey event... with will check the
current context (selected elements, etc..) and act as programmed by the
plugin designer.

*toolbar:*
*
*
It must export a function which returns: 1) the toolbar where it wants to
be in..
2) The icon that he wants to have
3) The tooltip for when user passes mouse over...

It's the system itself responsible for creating the toolbar icon in the
right place, and set events, not the plugin itself.

When somebody pushes the icon.. then the code executes...

*context menu plugin:*
1) It enumerates the kind of contexts+object selections where he wants to
pop up.
2) When this kind of context is happening, and the C++ software is creating
the context menu, it asks the plugin "what name do you want to show in the
context menu?" (usually it's an static name..)

3) If somebody clicks on this certain dynamically generated context menu
item, then the function on scripting is called.


I see no coupling to the wx, ... the C++ implementation can take care of
how that's done over the UI.


I'm not sure if that was your concern.


> My 5 cents for the plugin type list:
> - S3D_MODEL_PLUGIN for loading VRML/STEP/IGES,
>

I like it :)
you could "import freecad" and then do whatever you want...


> - 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.
>
>
I can't imagine the interface of that yet. :)


> Tom
>