[WebKit-devel] kdereview/kwebkitpart/cmake

Dawit Alemayehu adawit at kde.org
Sun Jan 31 22:27:11 CET 2010


On Sunday 31 January 2010 15:52:16 Urs Wolfer wrote:
> On Sun, 31 Jan 2010 12:47:26 -0500, Dawit Alemayehu <adawit at kde.org>
> 
> wrote:
> > On Sunday 31 January 2010 09:41:39 Urs Wolfer wrote:
> >> How should we handle this? For trunk its IMHO clear: just support this
> >> new
> >> version. What's about 4.4 branch?
> > 
> > I presume this question is in regards to the name change from
> 
> "WebKitPart"
> 
> > to
> > "KWebKitPart", right ? If so I personally I think both the trunk and
> 
> 4.4
> 
> > branch should be treated exactly the same way. Whatever is done in the
> > trunk
> > needs to be back ported to the branch as well
> 
> Ok, I have fixed the two cases in trunk (KGet and kttsplugins (or
> something like that...)). For KGet I also have fixed KWebKitPart support.
> Things should work again. Nothing backported yet, but I will do so.

ahhh... I guess the KGet webkit part support you provided is fine for now, but 
from what I saw what you did was simply restore what was there before with few 
additional changes, no ? Anyhow, here is my problem with it as it is now:

#1. In the showLinks function KHTML's class are used even when the current 
rendering engine is KWebKitPart!  That means using KGet's integration with 
KWebKitPart would result in multiple rendering engines being run. That should 
not be the case.

#2. Show selected links is not supported for KWebKitPart. Why ? What is 
lacking or is it because of the current hack used to add KWebKitPart support ?

#3. I thought the use of inherits(...) was discouraged long time ago when 
qobject_cast<...> came to the scene ?


> Dawit, will you care about extragear plugins? IIRC you have already fixed
> them recently.

I think I have already taken care of this if I remember correctly, but I will 
check it again.

Regards,
Dawit A.


More information about the WebKit-devel mailing list