"get hot new stuff" button

[Martijn Klingens]

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.

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. 

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.

Maybe it's all there, but I think at least parts of this are missing. Does 
anyone have more info for me here? Again, the example itself is completely 
fake, but the idea is definitely not. I could give you similar use cases for 
Kopete, or for many other programs I would like to see in KDE one day or 
another.

Martijn