Christian Wieninger wrote: > Hi, > >> It would have to know about exactly which parameters to provide, anyway. >> Where's the problem with including the proper header file? >> > > I agree with you, if the functions of the server-plugin are an essential > part of the client plugin. > But :-) > Take timeline for example and its timer conflict check. If its > installed, then epgsearch checks periodically if there are any timer > conflicts. If not, no problem. There's no dependence at compile- or > runtime. > Searching for repeats of using the extended timer edit menu is the same > thing. If epgsearch is present, a plugin can use this functions. But it has to know the semantics of that plugin in any case. You can't just put some random data into some abstract interface and expect something particular to happen ;-) So why not have the plugin that provides a certain functionality that's of interest to other plugins advertise this like any other library would do? The clean method is for the "server" to provide a proper public member function and for the "client" to include the plugin's header file. Determining whether or not a plugin is present doesn't change through that - you already do that now, don't you? Klaus
