[WebKit-devel] KParts::TextExtension

[Dawit A]

On Mon, Sep 27, 2010 at 7:44 AM, David Faure <faure at kde.org> wrote:
> 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?

Ahh... yes, we somehow need to obtain the url for each frame first don't we ?

QStringList frameUrls() const;
QString completeTextForFrame(const QString& frameUrl, Format) const;

Not sure whether this would then belong in KTextSelection either...

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

Great. I was not sure this would belong in this extension in the first
place either. Are you planning to use the standard CSS selectors for
this like QtWebkit or something along the lines of what I suggested
above ? Either way that should handle

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

Why ? Would not a simple #if KDE_IS_VERSION(....) suffice in both the
header and source files of kwebkitpart_ext ? Anyhow, you need not
worry about this since I have already created a stable branch for
kwebkitpart already:

http://websvn.kde.org/branches/stable/extragear-kde4/base/kwebkitpart/0.9/

I will bump the so version and make sure that kwebkitpart in
trunk/extragear requires KDE >= 4.5.69 to compile...

Regards,
Dawit A.