[WebKit-devel] KParts::TextExtension

Dawit A adawit at kde.org
Sat Sep 25 05:25:04 BST 2010


> The api is below for post-commit review :-)
> Now is a good time to ask for more virtual methods in there.

Here are a couple of virtual functions I can think of right away. I am
sure there are more that can be added once you scour the konq-plugins

#1. Access to HTML source of the frames in a page. This would help the
validators plugin. Perhaps something like:
virtual QStringList completeTextFromFrames(Format) const;

#2. Ability to obtain specific attributes from HTML/XHTML tags. For
example, the searchbar plungin needs the "href" attribute of the
<link> tags whole other attributes, "rel" and "type", match "search"
and "application/opensearchdescription+xml" respectively. Perhaps
something like:

struct AttributesParam {
    QString tagName;
    QString attributeName;
    QStringList filters;
    bool resolveIfUrl;
typedef QList<AttributeParams> AttributesParamList;
virtual QStringList attributes(const AttributesParamList&) const;

In addtion to the searchbar plugin, the above function will also work
for the kget and akregator plugins. There are others that might
benefit from such API as well. Need to check the ones that are
currently only KHTML specific...

That leaves the adblock plugin which currently has no dependency on
KWebKitPart, but lots of code duplication in both khtml and
kwebkitpart to handle this. I personally think creating a generic
method for filtering filtering requests at KIO level should be
something we consider for solving that issue... However, that is
another discussion altogether... :)

> The reason I'm posting this here, is to let other kpart authors know about it.
> For instance if katepart provides this extension then babelfish and text-to-
> speech would also work with it (e.g. in konqueror).
> I'll commit http://www.davidfaure.fr/2010/kttsplugin.diff (kdebase) on Monday,
> it leads to a pretty nice cleanup of that code.
> Question: when can I commit extragear/base/konq-plugins/babelfish, i.e. when
> can it depend on kdelibs trunk?
> Question for webkit-devel: when can I commit the use of TextExtension to
> extragear/base/kwebkitpart?
> http://www.davidfaure.fr/2010/webkit_textextension.diff

Yes, the only issue is the konq-plugins, much like everything else in
extragear, do not follow the normal branch and tagging cycle. If we
rely on code that depends on new API in kdelibs trunk, we have to
somehow ensure that people using the current release of kdelibs would
be able to continue comiling and using this stuff...

At least in kwebkitpart we have been using #ifdef'ed code to continue
support for KDE version back to 4.4 and up... I am sure at some point
I am going to have to resort to independent branching/tagging...

Dawit A.

More information about the kde-core-devel mailing list