[WebKit-devel] KParts::TextExtension

[David Faure]

On Saturday 25 September 2010, Dawit A wrote:
> Hi,
> 
> > 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
> directory...
> 
> #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;

This is an interesting point, I was wondering how to handle frames, too.
Ah, I see, with a QStringList you send each frame separately. But isn't this 
missing a filename of sorts, for each frame, in order to identify it?

> #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...

Yes, this is something I plan to address next, using 
querySelector/querySelectorAll wrappers. However this does not belong in 
TextExtension, since it's HTML/web-specific. As it is right now, TextExtension 
can also be used by katepart, okularpart etc.

Well, frames are also html-specific, but one could say they are like "pages" 
(which I added to TextExtension e.g. for okular), and anyway #1 is about 
returning text. #2 on the other hand is about returning structured 
information, which I'll do separately.

This is needed for searchbar but also for
konq-plugins/akregator/konqfeedicon.cpp

> 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... :)

Agreed.

> 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...

OK, I can use #ifdefs based on the KDE version, if we're fine with breaking 
compilation for people using "kdelibs trunk from between the 4.5.0 release and 
last friday". These people can update kdelibs. People using released versions 
will have no issue.
Hmm, ouch, I need to ifdef even the cmakelists.txt code. This is going to be 
ugly, and hard to test...

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).