Greetings Simon,
Apologies for my stupid change in advance.
My change just tried to straightforwardly implement a suggestion
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0545.html
without deep consideration about WebKit manners noted by your e-mail.
On Wed, Jun 22, 2011 at 1:17
2011/6/21 Hironori Bono (坊野 博典) hb...@chromium.org
On Wed, Jun 22, 2011 at 1:17 PM, Simon Fraser simon.fra...@apple.com
wrote:
This new API got turn on inadvertently on Mac just now, and a few of us
spent
a wasted hour trying to get things to build. In this light, my comments
on the API
Hi everyone,
Has anyone used Eclipse IDE on Ubuntu? If so do you have
any recommendations?
Thanks.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Hi,
Which port you want to build?
For Qt :
QtCreator for the Qt port works pretty well, just open the WebCore.pro
or QtWebKit.pro with it.
Though I've never tried Eclipse on the Qt port.
On Wed, Jun 22, 2011 at 10:19 AM, Tom Smith penguin.lin...@gmail.com wrote:
Hi everyone,
Has anyone
Hi,
I am wondering why webkit has the most documentation in cpp files. In header
files only classes, structures are documented. Is there any reason to do it
in that way?
If we will have all documentation in header files client programmer will
take devel package of webkit and he may generate a
On Jun 22, 2011, at 11:29 AM, Grzesiek Czajkowski wrote:
Hi,
Hi,
I am wondering why webkit has the most documentation in cpp files. In header
files only classes, structures are documented. Is there any reason to do it
in that way?
If we will have all documentation in header files
Hi Sam,
I'm one of Chrome's accessibility developers. I think this is a really
great idea, I think the ability for WebKit to do the searching rather
than the screen reader could be a big performance win for users.
In order to take advantage of this feature on multiple platforms, we'd
need to add
On Jun 22, 2011, at 7:29 AM, Grzesiek Czajkowski wrote:
I am wondering why webkit has the most documentation in cpp files. In header
files only classes, structures are documented. Is there any reason to do it
in that way?
If we will have all documentation in header files client programmer
The rollout is slightly complicated, but I'll take care of it.
Adam
2011/6/21 Ryosuke Niwa rn...@webkit.org:
2011/6/21 Hironori Bono (坊野 博典) hb...@chromium.org
On Wed, Jun 22, 2011 at 1:17 PM, Simon Fraser simon.fra...@apple.com
wrote:
This new API got turn on inadvertently on Mac just
Thank you, Adam.
Given this fiasco, I'm temped to propose that we require two levels of review
for new web-facing API.
Simon
On Jun 22, 2011, at 10:43 AM, Adam Barth wrote:
The rollout is slightly complicated, but I'll take care of it.
Adam
2011/6/21 Ryosuke Niwa rn...@webkit.org:
On Wed, Jun 22, 2011 at 11:28 AM, Simon Fraser simon.fra...@apple.comwrote:
Thank you, Adam.
Given this fiasco, I'm temped to propose that we require two levels of
review for new web-facing API.
That sounds reasonable. But adding, say, new CSS property or supporting new
event that has been
I think it's better for our reviewers to review only things they're
comfortable with.
We could also teach bots (like the style-bot) to complain when seeing new API.
I'd rather not add another layer of process.
-eric
On Wed, Jun 22, 2011 at 11:31 AM, Ryosuke Niwa rn...@webkit.org wrote:
On
On Jun 22, 2011, at 11:38 AM, Eric Seidel wrote:
I think it's better for our reviewers to review only things they're
comfortable with.
It might be worth going back to this patch, figuring out who reviewed it, and
making sure that person understands that they did not look sufficiently at the
It's partially my fault. I saw the train wreck coming, but got
distracted with other stuff and did not follow through.
I think the problem was that:
1) I should've been more firm in insisting on waiting for feedback
from webkit-dev.
2) Brent had no business reviewing that patch.
To prevent this
On Jun 22, 2011, at 11:38 AM, Eric Seidel wrote:
I think it's better for our reviewers to review only things they're
comfortable with.
A good reviewer shouldn't be reviewing things they aren't comfortable with
anyway -- the whole point of a review is to have someone who has appropriate
On Wed, Jun 22, 2011 at 11:38 AM, Eric Seidel e...@webkit.org wrote:
I think it's better for our reviewers to review only things they're
comfortable with.
But I don't think being comfortable may not necessarily mean that the
reviewer knows all implications of the change.
On Wed, Jun 22,
Per IRC discussion, I propose to add a Wiki page that states what needs to
be checked/reviewed for new Web-facing API to avoid adding new
policy/process to the review process. This page is not meant as a mandatory
checklist but rather a guide that reviewers can use to ensure he/she is
reviewing
On Wed, Jun 22, 2011 at 11:41 AM, Dimitri Glazkov dglaz...@chromium.org
wrote:
To prevent this from happening again, we should remind everyone to:
1) Only review things they are comfortable with;
2) Seek WebKit elder's review for public-facing APIs
I don't think we need an explicit
I just had another thought: how would this work in a multi-process browser?
As you may know, Chrome runs an instance of webkit in a separate
renderer process for each tab, but the GUI and all accessibility
handling happens in the main browser process. Because accessibility
calls are synchronous,
On Jun 22, 2011, at 3:34 PM, Dominic Mazzoni wrote:
I just had another thought: how would this work in a multi-process browser?
As you may know, Chrome runs an instance of webkit in a separate
renderer process for each tab, but the GUI and all accessibility
handling happens in the main
On Wed, Jun 22, 2011 at 4:21 PM, Chris Fleizach cfleiz...@apple.com wrote:
I think this is one drawback of Chrome's approach, the inability to retrieve
dynamic information. I suspect Chrome has similar issues for the
NSAccessibilityParameterizedAttribute attributes, and that it doesn't
On Wed, Jun 22, 2011 at 4:21 PM, Chris Fleizach cfleiz...@apple.com wrote:
On Jun 22, 2011, at 3:34 PM, Dominic Mazzoni wrote:
I just had another thought: how would this work in a multi-process
browser?
As you may know, Chrome runs an instance of webkit in a separate
renderer process
Hey Dominic,
Thanks for the feedback. I've been prototyping this idea here and it does
included text searching as you mentioned. My philosophy was to put the search
functionality right into the AccessibilityObject class and leave the job of
exposing external APIs up to the experts of each
On Jun 22, 2011, at 3:21 PM, Dominic Mazzoni wrote:
On Wed, Jun 22, 2011 at 3:14 PM, Samuel White samuel_wh...@apple.com wrote:
Thanks for the feedback. I've been prototyping this idea here and it does
included text searching as you mentioned. My philosophy was to put the
search
On Jun 22, 2011, at 4:29 PM, James Robinson wrote:
On Wed, Jun 22, 2011 at 4:21 PM, Chris Fleizach cfleiz...@apple.com wrote:
On Jun 22, 2011, at 3:34 PM, Dominic Mazzoni wrote:
I just had another thought: how would this work in a multi-process browser?
As you may know, Chrome runs
Greetings Adam,
Thank you for reverting this change on my behalf. (I agree it is not so easy.)
I will re-implement this API to apply comments, wishing the next
change becomes the better one.
Regards,
Hironori Bono
E-mail: hb...@chromium.org
On Thu, Jun 23, 2011 at 2:43 AM, Adam Barth
26 matches
Mail list logo
