[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: kdewebkit moved to kdereview
From:       Albert Astals Cid <tsdgeos () yahoo ! es>
Date:       2009-10-27 9:28:21
Message-ID: 236478.29856.qm () web27208 ! mail ! ukl ! yahoo ! com
[Download RAW message or body]

--- El mar, 27/10/09, Dawit A. <adawit@kde.org> escribió:

> De: Dawit A. <adawit@kde.org>
> Asunto: Re: kdewebkit moved to kdereview
> Para: kde-core-devel@kde.org
> Fecha: martes, 27 de octubre, 2009 07:00
> 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@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 ? 
> 

No, sadly i can't since they already said on IRC they have given up trying to make \
people understand this, so obviously they don't want to be dragged into this \
discussion.

But the reasons seem obvious to me, Safari is based on a given webkit revision, \
Chrome in a different one and QtWebkit in a different one, so they have different \
bugs. They are close enough, yes, but so is KHTML and that still doesn't give us the \
bug-for-bug feature.

Albert


      


[prev in list] [next in list] [prev in thread] [next in thread]