kdewebkit moved to kdereview

[Thiago Macieira]

Em Domingo 25. Outubro 2009, às 21.08.13, Albert Astals Cid escreveu:
> A Diumenge, 25 d'octubre de 2009, Albert Astals Cid va escriure:
> > 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?
> 
> Ok, let me say it in different words for it to be clear since some people
>  do not want to understand.
> 
> kdelibs has KHTML, we don't need webkit at all.

That's oversimplifying things. KHTML is great, but it's also behind WebKit in 
many of the recent technologies.

> The problem is that Nokians agenda is kill KHTML in favor of QtWebkit.

And what would be the harm if it happened? If we had a more powerful engine, 
that has a bigger community maintaining it, that websites actually test, would 
it be such a great loss?

Loss of control? Fork it like everyone else does for their own releases. But 
upstream the changes later, like everyone else does.

Besides, QtWebKit is already preloaded into every kdeinit application anyway, 
including Konqueror.

That said, I don't think the webkitpart is ready for review state. It's not 
feature-complete yet.

> I only want to remind you the fiasco (Can't print in okular. can't do
>  poster printing. why i can't print only odd pages?) of the killing of
>  KDEPrint by forcing QPrinter on us that never got fixed and we are still
>  suffering the consequences by asking us to rewrite what we already had
>  working.

And I'll remind you of the state that KDE Print was before: it had been 
unmaintained for years. It had lots of CUPS-specific code that was hard to 
maintain.

During the KDE 4 port, it was mostly left untouched, aside from the occasional 
"qt3support--" commits.

Now, John Layt has been working on improving the situation. But he hasn't 
finished yet. In fact, he hasn't submitted a single patch for review. The 
printer maintainers in the office don't even know he's doing anything.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20091025/1fa9f228/attachment.sig>