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