"get hot new stuff" button

[Simon Hausmann]

On Sat, Jun 22, 2002 at 12:56:46PM +0200, Martijn Klingens wrote:
> On Saturday 22 June 2002 10:59, Simon Hausmann wrote:
> > > The following sub-cases can be refined from that:
> > > 1. The visualization API plugin itself is useless without a plugin
> > > implementing the API, so it should not appear as selectable in the GUI,
> > > but rather be hidden. A simple flag in the .desktop file should probably
> > > do it.
> >
> > Why would it be a noatun plugin if it does not behave as such? I
> > think it should rather be a normal shared library that other
> > libraries/binaries can depend on.
> 
> Hmm, that *could* be done, but I think it's a bit clumsy to have such a hybrid 
> of .so files installed in two different paths. Not to mention that the API 
> .so doesn't really belong in a general library path, because it's only 
> plugins that use it. Then better add the plugin path to LD_LIBRARY_PATH just 
> before loading the viz plugin so the API is picked up automatically.

Why is it clusmy? It is in no way different that say having
libkonq in $libdir. As soon as you have a library that other
libraries or binaries link against you should put it into $libdir.

> Also, if app X is installed in a prefix != the KDE prefix you not only need to 
> add the prefix to KDEDIRS (which I already dislike - the app's install prefix 
> should AFAICS be added to KDEDIRS on startup and not require fiddling with 
> environment variables to be user friendly, but that's another issue), but you 
> also need to add the prefix to the library path in order to have the linked 
> .so files be found. Again a pain to administer and if you ask me a needless 
> pain. It's bound to cause bug reports because people are not aware of it.

Because it requires more work either way (think of $PATH)
administrators re-use existing prefixes (or use stow) . At least
lazy ones :)

> > > 2. The visualization API plugin is required by the implementing plugins
> > > and should hence be loaded automatically when one of those plugins is
> > > loaded and unloaded when all of them are unloaded. Some form of
> > > refcounting is probably needed here, and dependency checking and
> > > resolving code. Relying on the os' dynamic loader is not possible because
> > > plugins are not in LD_LIBRARY_PATH.
> >
> > What kind of dependency do other plugins have on the visualization
> > API plugin? A real DSO dependency, requiring the viz API plugin to
> > be loaded before and requirinig it to export symbols the others
> > depend on?
> 
> A viz plugin requires the viz API to be loaded, something that can be 
> specified in the desktop file (requireAPI=viz, foo, bar) or in another way. 
> 
> And in some cases it's a runtime dependency that cannot be resolved by the 
> dynamic linker anyway. Kopete's auto-away plugin requires a protocol plugin 
> to be loaded, but the API itself is always available, so a DSO dependency 
> won't work. The plugin would load, but it would be completely useless without 
> protocols active. Of course Kopete itself is also useless without protocols 
> loaded, but it's not hard to come up with examples where such a scenario is 
> real.

Aha, that's indeed a dependency that needs to be handled by our
framework. You're right here.

Simon