"get hot new stuff" button

[Simon Hausmann]

On Sat, Jun 22, 2002 at 02:46:46AM +0200, Martijn Klingens wrote:
> On Friday 21 June 2002 08:02, David Faure wrote:
> > On Thursday 20 June 2002 23:56, Cornelius Schumacher wrote:
> > > By the way, how many different plugin loading frameworks do we have in
> > > KDE?
> >
> > Only one and it's called KLibLoader+KTrader ;)
> >
> > What's missing as a common solution is a way to enable/disable plugins,
> > including a listview with checkboxes for the GUI part of it - Matthias
> > Kretz is working on it.
> 
> To pick a possible use case from noatun (probably fake, I don't know the code, 
> but it's along the way I'm thinking for a number of potential projects and 
> understandable for everyone): does the current code handle the case where 
> visualization plugin Foo and visualization plugin Bar both require the 
> visualization API plugin? Or the visualization DCOP bindings plugin for that 
> matter?
> 
> 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.

> 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?

See first paragraph. Otherwise if the viz API plugin also provides
a noatun plugin then IMHO it should be a shared library installed
into $libdir, so it can be dlopened but also found by the dynamic
loader.

I think re-implementing what ld.so already provides (dependency
tracking) isn't necessary.

> 3. The API plugin provides an API and hence requires an implementation to be 
> loaded as well. This sounds redundant given #1, but it is not. A plugin like 
> the visualization DCOP bindings, that does implement code (and hence is 
> selectable by the user) might extend an API. Selecting this plugin *requires* 
> that at least one implementation of the API itself is also available. This 
> requires a simple trader mechanism, but I have no idea if KTrader can be used 
> 'as is' for that or needs refinement.

[ can't see any difference to the above cases ]

Simion