kdewebkit moved to kdereview
Dawit A.
adawit at kde.org
Tue Oct 27 06:00:15 GMT 2009
On Monday 26 October 2009 14:41:23 Albert Astals Cid wrote:
> A Dilluns, 26 d'octubre de 2009, Marco Martin va escriure:
> > On Sun, Oct 25, 2009 at 8:58 PM, Albert Astals Cid <aacid at 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.
You are entitled to your own opinions, but you are not entitled to your own
facts ; so can you please point us to these people who understand how webkit
works so we can ask this very question ?
More information about the kde-core-devel
mailing list