kicad-developers team mailing list archive

[Vladimir Uryvaev <vovanius@xxxxx>]

At Monday 28 of November 2011 01:52:44 from Dick Hollenbeck:
> I believe you are thinking that a directory scan is done for DLL/DSOs, then
> they are each loaded, queried and added to a collection.

For loading-on-demand proxy-objects are exist. For example, one may use module 
features through double dispatch: plugin->pcb_io()->save(...), where 
PLUGIN::pcb_io() member load the plugin (at IO part) on demand (or throw an 
exception if it's unavailable).

 
> Since we are dealing with the open source world, it will be mostly the case
> that we know which plugins are available ahead of time, since they will be
> compiled with the project. This is where I got my direction.

If a module is not accessible konwledge about it is useless, isn't it? 
Nevertheless stub object can be used for this.

> 
> Secondly, there are sadly problems in the objects of KiCad which make
> making a DLL/DSO problematic, and this includes the fact that each object
> has its own Draw() member function.  We do not want Draw() support down in
> a DLL/DSO plugin, where we only want to load and save the objects, not
> draw them.  This means linking becomes a problem.

They can not be only binary objects, but also scripts or IPC-proxies. For 
example external router may look like a plugin, but actually it is an external 
program controlled through IPC.
-- 

--- KeyFP: DC07 D4C3 BB33 E596 CF5E  CEF9 D4E3 B618 65BA 2B61