"get hot new stuff" button
klingens at kde.org
Sat Jun 22 01:46:46 BST 2002
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
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
More information about the kde-core-devel