On 04/04/2013 09:14 PM, Ryosuke Niwa wrote:
On the other hand, I don't think optimizing WebCore for JSC doesn't
necessarily mean it'll become impossible for you to have a custom build
of WebKit that uses some other binding code. For example, Mac has
Objective-C bindings and that's not going
Hi,
This is somewhat related to the bulk move of Chromium-WebKit contributors
to Blink, but we might want to consider sunsetting/expiring committership
and reviewership.
I'm thinking of something like expiring committership/reviwership of a
person after the person didn't have any SVN activities
Hi,
The Qt port of WebKit (based on Qt 5.x) does not use v8.
(Qt 5.x uses v8 in other places, but that is not relevant to the WebKit project
and this discussion)
Simon
Markus kamika...@gmx.de wrote:
For the record though I don't think Qt is using any of that those.
Qt 5.x uses V8.
I am not sure this is really needed. People sometimes disappear from
working on trunk for extended periods of time due to internal products
and downstream branches. It has happened multiple times to me. That
doesn't mean that I won't come back and start working upstream later.
Also it could be
On Apr 5, 2013, at 2:19 AM, Ryosuke Niwa rn...@webkit.org wrote:
Hi,
This is somewhat related to the bulk move of Chromium-WebKit contributors to
Blink, but we might want to consider sunsetting/expiring committership and
reviewership.
I'm thinking of something like expiring
Am 05.04.2013 um 08:19 schrieb Ryosuke Niwa rn...@webkit.org:
Hi,
This is somewhat related to the bulk move of Chromium-WebKit contributors to
Blink, but we might want to consider sunsetting/expiring committership and
reviewership.
I'm thinking of something like expiring
On Apr 4, 2013, at 11:19 PM, Ryosuke Niwa rn...@webkit.org wrote:
Hi,
This is somewhat related to the bulk move of Chromium-WebKit contributors to
Blink, but we might want to consider sunsetting/expiring committership and
reviewership.
I'm thinking of something like expiring
On Thu, Apr 4, 2013 at 11:53 PM, Kenneth Rohde Christiansen
kenneth.christian...@gmail.com wrote:
I am not sure this is really needed. People sometimes disappear from
working on trunk for extended periods of time due to internal products
and downstream branches. It has happened multiple times
On Thu, Apr 4, 2013 at 11:56 PM, Nikolas Zimmermann
zimmerm...@physik.rwth-aachen.de wrote:
Am 05.04.2013 um 08:19 schrieb Ryosuke Niwa rn...@webkit.org:
Hi,
This is somewhat related to the bulk move of Chromium-WebKit
contributors to Blink, but we might want to consider
Neither here nor there, but...
I had interest in sunsetting committers/reviewers in the past. There
are loads of folks listed in committers.py who haven't committed or
reviewed in 5+ years. I believe there are some old threads on
webkit-reviewers about such.
I believe the timeout for
Sorry. Wrong address again.
On Fri, Apr 5, 2013 at 12:09 AM, Eric Seidel esei...@google.com wrote:
Neither here nor there, but...
I had interest in sunsetting committers/reviewers in the past. There
are loads of folks listed in committers.py who haven't committed or
reviewed in 5+ years.
Sent from my iPhone
On Apr 5, 2013, at 12:00 AM, Ryosuke Niwa
rn...@webkit.orgmailto:rn...@webkit.org wrote:
On Thu, Apr 4, 2013 at 11:53 PM, Kenneth Rohde Christiansen
kenneth.christian...@gmail.commailto:kenneth.christian...@gmail.com wrote:
I am not sure this is really needed. People
On Apr 4, 2013, at 11:19 PM, Ryosuke Niwa rn...@webkit.org wrote:
Hi,
This is somewhat related to the bulk move of Chromium-WebKit contributors to
Blink, but we might want to consider sunsetting/expiring committership and
reviewership.
I'm thinking of something like expiring
On Fri, Apr 5, 2013 at 12:21 AM, Maciej Stachowiak m...@apple.com wrote:
On Apr 4, 2013, at 11:19 PM, Ryosuke Niwa rn...@webkit.org wrote:
Hi,
This is somewhat related to the bulk move of Chromium-WebKit contributors
to Blink, but we might want to consider sunsetting/expiring committership
Hi,
On Fri, Apr 5, 2013 at 12:19 AM, Benjamin Poulain benja...@webkit.orgwrote:
I don't know exactly what is the problem with integrating Qt...but I think
fixing that will be far less work than making a new WebKit2 port from
scratch.
WebKitGTK+ also run on Windows. But I don't know if it
Hi Geoff,
First of all, let me say upfront that I see all the potential advantages of
sticking to just one JS engine, and also perfectly understand the points
that most of the people here have made on favour of not supporting multiple
engines.
Also, my mail was not really a formal request to
On Qui, 2013-04-04 at 18:46 +0200, Balazs Kelemen wrote:
FWIW, mrobinson has been working on a GYP build for the GTK port, so I
wouldn't delete all of the .gyp files (at least not w/o them weighing
in on it). I thought there was some interest at Apple in also using
GYP, but perhaps things
Also, WebP project is unfinished state right now. This changeset requires
libwebp version 0.3.0:
https://trac.webkit.org/changeset/147048
But version 0.3.0 also supports animated webp, and google doesn't have the
code for animation support in WEBPImageDecoder.cpp yet, not even in
Chromium.
So
Hi Mario.
First of all, let me say upfront that I see all the potential advantages of
sticking to just one JS engine, and also perfectly understand the points
that most of the people here have made on favour of not supporting multiple
engines.
Also, my mail was not really a formal request
On Friday 05 April 2013, Max Stepin wrote:
Also, WebP project is unfinished state right now. This changeset requires
libwebp version 0.3.0:
https://trac.webkit.org/changeset/147048
To me it looks more like it requires 0.3.0 to enable color correction. Older
ABIs are still supported.
`Allan
To me it looks more like it requires 0.3.0 to enable color correction.
Older ABIs are still supported.
Yes, but some WebP images (created with 0.3.0) will not work.
I tried, not even the first frame is displayed.
Would it be OK to just take future WEBPImageDecoder.cpp updates from Chromium?
There are plenty of other bindings - Gtk has a set of dom bindings i believe,
there used to be COM (shudder) bindings as well, but those aren't the problem.
We could have as many binding languages as we want, there's no major
architectural reason not to.
But supporting javascript isn't simply
On Friday 05 April 2013, Max Stepin wrote:
To me it looks more like it requires 0.3.0 to enable color correction.
Older ABIs are still supported.
Yes, but some WebP images (created with 0.3.0) will not work.
I tried, not even the first frame is displayed.
Would it be OK to just take
On Apr 5, 2013, at 5:25 AM, Mario Sanchez Prada mario.pr...@samsung.com wrote:
Also, my mail was not really a formal request to keep the V8 bits around in
the long term, but just a quick reply to the following comment from Maciej:
Geoff posted the list in part because we'd like to
On Friday, April 05, 2013 09:24:59 AM Geoffrey Garen wrote:
Hi Mario.
First of all, let me say upfront that I see all the potential advantages
of
sticking to just one JS engine, and also perfectly understand the points
that most of the people here have made on favour of not supporting
On Thu, Apr 4, 2013 at 9:18 PM, Ryosuke Niwa rn...@webkit.org wrote:
I've temporarily disabled testing on the commit queue in
http://trac.webkit.org/changeset/147695 since we haven't added enough
hardwares to keep up with patches.
I'll re-enable testing once we've got up to speed. Again,
26 matches
Mail list logo
