kicad-developers team mailing list archive
Mailing list archive
Re: Was: request for comments on work package list, is now: IO_MGR
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