[WebKit-devel] KParts::TextExtension

[Albert Astals Cid]

A Dilluns, 27 de setembre de 2010, Albert Astals Cid va escriure:
> A Dilluns, 27 de setembre de 2010, Dawit A va escriure:
> > 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 undestand form the 0.9 part that you plan to have multiple versions of
> kwebkitpart under branches/stable/extragear-kde4
> 
> This is not supported since scripty processes that directory and when you
> have two versions there it would confused as hell.
> 
> The typical workflow is having your current stable branch in
> branches/stable/extragear-kde4 and your "old stable" brances in
> branches/myprogramname/version

And now i see you deleted branches/stable/extragear-kde4/base/kwebkitpart ?

What's the rationale for not wanting it there anymore? You don't have a stable 
branch anymore? You have one but don't want it to be translated?

Albert

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