[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: using qcom interfaces wit parts (was Re: Plugins for non-major Parts)
From:       Kurt Granroth <granroth () suse ! com>
Date:       2001-09-14 16:16:50
[Download RAW message or body]

On Thursday 13 September 2001 03:13 pm, Waldo Bastian wrote:
> > Put another way, the problem is that while Plugins are intended to be an
> > after-the-fact third-party way of interacting with existing Parts, the
> > current reality is that only the *major* Parts like KHTMLPart and
> > KonqDirPart allow this.  That is because BY DEFAULT, we don't give any
> > way for Plugins to discover the interface of the Part.  The header files
> > aren't installed and while the Parts are in shared libs, they aren't
> > accessible for linking.
>
> But isn't "kpart/part.h" or e.g. "ktexteditor.h" the interface of the part?

Okay, time for some very concrete examples :-)

Most of the plugins that exist so far are for KHTMLPart or KonqDirPart.  The 
plugins that deal with KHTMLPart access such properties as the currently 
selected text, the current URL, the DOM tree, etc.  *ALL* of these properties 
and methods are specific to KHTMLPart, not to KParts::Part.  Therefore, if I 
#include <kpart/part.h>, it's not enough.  The interface for a simple Part is 
quite simple and it doesn't allow for me to access derived-Part specific 
methods and properties.

Narrowed down even more, in order to access the KHTMLPart's DOM tree, the Dom 
Tree Viewer plugin *needs* a handle on an actual KHTMLPart.  Therefore, the 
plugin needs to #include <khtml_part.h> and link to libkhtml

Now let's look at another Part.  I am on-and-off working to convert Klipper 
to a KPart in order to use Plugins in it (hence my questions, btw).  The 
KlipperPart has such properties as the clipboard and the currently selected 
item.  *Somehow*, for a plugin (like a babelfish one, for instance) to be 
able to access this content, it needs to be able to query the KlipperPart for 
it.  Keep in mind that there is nothing in KParts::Part that inherently allow 
this to happen.  Right now, it's not easily possible since

a) we don't install the klipperpart.h header file by default
b) we don't put libklipperpart.so into a "normal" lib directory

As it turns out, this isn't the perfect example of the problem because I can 
solve my problem using simple signals and slots.  However, if I was writing a 
plugin for KHTMLPart and it *didn't* have it's header and libs installed 
(like normal Parts), then there is no possible way that a plugin like the Dom 
Tree Viewer could be written (I think, I didn't look at it *that* closely).
-- 
Kurt Granroth            | http://www.granroth.org
KDE Developer/Evangelist | SuSE Labs Open Source Developer
granroth@kde.org         | granroth@suse.com
            KDE -- Conquer Your Desktop

[prev in list] [next in list] [prev in thread] [next in thread]