From kfm-devel Fri Sep 14 16:16:50 2001 From: Kurt Granroth Date: Fri, 14 Sep 2001 16:16:50 +0000 To: kfm-devel Subject: Re: using qcom interfaces wit parts (was Re: Plugins for non-major Parts) X-MARC-Message: https://marc.info/?l=kfm-devel&m=100048425817604 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 , 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 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