Love your work Adam, Eric and all involved with this project.
On 22 July 2010 11:30, Adam Barth aba...@webkit.org wrote:
We're getting close to enabling the HTML5 tree builder on trunk. Once
we do that, we'll have the core of the HTML5 parsing algorithm turned
on, including SVG-in-HTML.
Patches sit in the queue for numerous reasons. Some of us used to
scan the queue every day. But I've stopped doing that. Now I scan it
more like once a week or two.
There is no good way to find which patches might I have a chance of
reviewing, so you end up spending 30 minutes just to
On Jul 21, 2010, at 3:41 PM, Eric Seidel wrote:
Wow. I really like this idea of helping contributors better
understand what's going wrong.
But, I think that even better would be to build a better front-end for
reviews. Or a bot which knew how to suggest reviewers (based on
annotate
On Thu, Jul 22, 2010 at 8:29 AM, Maciej Stachowiak m...@apple.com wrote:
I think a better UI for reviews, plus some better attempts at active
notification of potential reviewers, could go a long way. I'm a strong
believer in trying nudges and positive incentives before implementing harsher
On Wed, Jul 21, 2010 at 8:57 PM, Steve Block stevebl...@google.com wrote:
Another argument for the setter is that it makes it easier to inject a
mock for testing in response to a LayoutTestController method call, by
simply calling the setter again to replace the real client with a mock
Hi,
Is WebKit well parallel for fitting in multicore architecture? And any
status for the parallel Webkit? The same idea is from
http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/
Thanks,
-Ying
___
webkit-dev mailing list
Hi Ying,
you might be looking for WebKit2, wich is a non-blocking API layer for
WebKit and aims to make WebKit more suitable for multicore systems. It
supports the split-process model and the thread model as well. The API
is currently under development for the Mac and Windows ports of WebKit
Sorry to disturb this already dead thread, but we're (webkit-efl)
thinking of letting applications/browsers register new protocol
handlers to provide contents themselves. A co-worker, Flávio Ceolin,
will send more details in another thread, but do you have any idea on
the path to have them
I wasn't entirely sure what OP was after of if the reply below
adequately addressed his interests. After looking at the link
provided, I thought I would make a few comments that may or
may not be of much benefit ( for discussion ) but that relate
to observations on a few recent browsers on one
I've filed https://bugs.webkit.org/show_bug.cgi?id=42834 to track the
addition of a structure to pass pointers to the clients for optional
features. Feedback welcome.
Steve
--
Google UK Limited
Registered Office: Belgrave House, 76 Buckingham Palace Road, London SW1W 9TQ
Registered in England
On Jul 22, 2010, at 2:12 PM, Gustavo Sverzut Barbieri wrote:
Sorry to disturb this already dead thread, but we're (webkit-efl) thinking of
letting applications/browsers register new protocol handlers to provide
contents themselves. A co-worker, Flávio Ceolin, will send more details in
We should also publicize/update these existing resources to help patch authors
find reviewers for their patches:
http://trac.webkit.org/wiki/CodeReview
http://trac.webkit.org/wiki/WebKit%20Team
I think the most effective approach is when patch authors proactively seek out
reviewers. We're all
12 matches
Mail list logo
