[prev in list] [next in list] [prev in thread] [next in thread]
List: webkit-dev
Subject: Re: [webkit-dev] Changes in QtWebKit development
From: Oliver Hunt <oliver () apple ! com>
Date: 2013-10-01 18:02:30
Message-ID: 5F0BD2DB-7DD3-4CA7-A2EA-EFDE00F905ED () apple ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Oct 1, 2013, at 12:50 AM, Allan Sandfeld Jensen <kde@carewolf.com> wrote:
> On Monday 30 September 2013, Oliver Hunt wrote:
> > On Sep 30, 2013, at 7:41 AM, Allan Sandfeld Jensen <kde@carewolf.com> wrote:
> > > Some of this is exactly the reason we want to keep Qt WebKit alive. It
> > > may never be possible to fully replace Qt WebKit with anything
> > > Blink/Chromium based.
> >
> > I really don’t understand this, there are only two options:
> > 1. Qt Webkit is critical to you and you want to support and maintain it,
> > and do all the work necessary for that; or 2. Qt WebKit is not critical,
> > and so you could simply branch and have a permanent stable release
> > platform similar to what the S60 port did years ago.
> >
> > Currently you seem to be arguing for a third option, wherein all of the
> > WebKit developers need to deal with your port, and be hamstrung by the
> > numerous invasive Qt-isms scattered throughout the codebase, for a port
> > that isn’t considered critical to its own platform.
> >
> Actually I am arguing we should get rid of most of the invasive Qt'ism unless
> they are really required for Qt WebKit to even work. Many of them were only
> necessary due to having to support so many platforms. With a more narrow focus
> we can hopefully get rid of 90% of the burden. If it turns out not to be
> possible in the end, we can always leave after having helped as far as we
> could.
>
But why should webkit have _any_ burden when Qt itself cares so little about QtWebKit \
that it is happy to have qtisms that were ostensibly necessary for performance, etc \
removed?
My reading of that is that you are more willing to have the quality of QtWebKit \
deteriorate than to simply fork off a final high quality stable branch.
I don’t believe WebKit should be taking _any_ burden for a port that is primarily \
focused on a completely separate fork in an unrelated tree.
So could you please say whether the QtWebKit plan going forward is option 1 or option \
2.
—Oliver
> Best regards
> `Allan
[Attachment #5 (text/html)]
<html><head><meta http-equiv="Content-Type" content="text/html \
charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: \
space; -webkit-line-break: after-white-space;"><br><div><div>On Oct 1, 2013, at 12:50 \
AM, Allan Sandfeld Jensen <<a \
href="mailto:kde@carewolf.com">kde@carewolf.com</a>> wrote:</div><br \
class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: \
12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: \
normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; \
text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; \
-webkit-text-stroke-width: 0px;">On Monday 30 September 2013, Oliver Hunt \
wrote:<br><blockquote type="cite">On Sep 30, 2013, at 7:41 AM, Allan Sandfeld Jensen \
<<a href="mailto:kde@carewolf.com">kde@carewolf.com</a>> wrote:<br><blockquote \
type="cite">Some of this is exactly the reason we want to keep Qt WebKit alive. \
It<br>may never be possible to fully replace Qt WebKit with \
anything<br>Blink/Chromium based.<br></blockquote><br>I really don’t understand this, \
there are only two options:<br>1. Qt Webkit is critical to you and you want to \
support and maintain it,<br>and do all the work necessary for that; or 2. Qt WebKit \
is not critical,<br>and so you could simply branch and have a permanent stable \
release<br>platform similar to what the S60 port did years ago.<br><br>Currently you \
seem to be arguing for a third option, wherein all of the<br>WebKit developers need \
to deal with your port, and be hamstrung by the<br>numerous invasive Qt-isms \
scattered throughout the codebase, for a port<br>that isn’t considered critical to \
its own platform.<br><br></blockquote>Actually I am arguing we should get rid of most \
of the invasive Qt'ism unless<span \
class="Apple-converted-space"> </span><br>they are really required for Qt WebKit \
to even work. Many of them were only<span \
class="Apple-converted-space"> </span><br>necessary due to having to support so \
many platforms. With a more narrow focus<span \
class="Apple-converted-space"> </span><br>we can hopefully get rid of 90% of the \
burden. If it turns out not to be<span \
class="Apple-converted-space"> </span><br>possible in the end, we can always \
leave after having helped as far as we<span \
class="Apple-converted-space"> </span><br>could.<br><br></div></blockquote><div><br></div><div>But \
why should webkit have _any_ burden when Qt itself cares so little about QtWebKit \
that it is happy to have qtisms that were ostensibly necessary for performance, etc \
removed?</div><div><br></div><div>My reading of that is that you are more willing to \
have the quality of QtWebKit deteriorate than to simply fork off a final high quality \
stable branch.</div><div><br></div><div>I don’t believe WebKit should be taking _any_ \
burden for a port that is primarily focused on a completely separate fork in an \
unrelated tree.</div><div><br></div><div>So could you please say whether the QtWebKit \
plan going forward is option 1 or option \
2.</div><div><br></div><div>—Oliver</div><br><blockquote type="cite"><div \
style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: \
normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: \
start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; \
word-spacing: 0px; -webkit-text-stroke-width: 0px;">Best \
regards<br>`Allan</div></blockquote></div><br></body></html>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic