From kde-core-devel  Mon Oct 26 18:41:23 2009
From: Albert Astals Cid <aacid () kde ! org>
Date: Mon, 26 Oct 2009 18:41:23 +0000
To: kde-core-devel
Subject: Re: kdewebkit moved to kdereview
Message-Id: <200910261941.23783.aacid () kde ! org>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=125658261831162

A Dilluns, 26 d'octubre de 2009, Marco Martin va escriure:
> On Sun, Oct 25, 2009 at 8:58 PM, Albert Astals Cid <aacid@kde.org> wrote:
> > A Diumenge, 25 d'octubre de 2009, Urs Wolfer va escriure:
> >> On Sunday 25 October 2009 20:31:25 Albert Astals Cid wrote:
> >> > A Diumenge, 25 d'octubre de 2009, Urs Wolfer va escriure:
> >> > > I have just moved the kdewebkit lib from
> >> > >  playground/libs/webkitkde/kdewebkit into kdereview. It's the KDE
> >> > >  integration part of QtWebKit which is used directly in many apps
> >> > > and libs already (...which does *not* include the WebKit KPart). Any
> >> > > KDE app is supposed to move to this integration lib when it is in
> >> > > kdelibs (plans are to move it to kdelibs/kdewebkit).
> >> > >
> >> > > It requires an up-to-date kdelibs because of recent changes in KIO.
> >> > >
> >> > > There is still a copy of it in playground/libs/webkitkde/kdewebkit
> >> > > in order to allow building the WebKit KPart without kdereview.
> >> > > Please do not work anymore with this copy, but use the kdereview
> >> > > copy! I will drop the playground copy as soon as has been moved to
> >> > > kdelibs.
> >> >
> >> > What's the use case of this?
> >>
> >> Many distributions create packages for the WebKit KPart. That's why I do
> >>  not want to depenend on kdelibs trunk and kdereview parts. It would
> >> only introduce additional complexity.
> >
> > That's not what i asked, what i asked is why this code should go to
> > kdelibs, what does it give over the technologies we already have there?
> 
> the most important thing is to have something that people would use.
> right now even most of kde developers are using firefox, because there
> are many many sites that with khtml simply won't work.
> with webkit one can hope that site creators will test the site on some
> variant of it, with khtml we will be always condemned to chase them
> and unbreak khtml only after the damage is done.

Talk to anyone that understands how webkit works and will tell you that the 
mythical bug-for-bug "feature" with safari/chrome does not exist, so basically 
you end up using webkit-qt instead of khtml and having the same problems of 
using a very minor browser noone tests against.

Albert

> it's sad, it's unfair, but that's life.
> 
> > Albert
> >
> >> Bye
> >> urs
> 
> Marco Martin
>