On Fri, Jul 6, 2012 at 11:49 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Jul 6, 2012 3:16 PM, Per Bothner per.both...@oracle.com wrote:
On 07/06/2012 02:02 PM, Ryosuke Niwa wrote:
On Fri, Jul 6, 2012 at 12:54 PM, Per Bothner per.both...@oracle.com
wrote:
You're deluding yourself if you
On Wed, Jul 11, 2012 at 6:54 AM, John Mellor joh...@chromium.org wrote:
On Fri, Jul 6, 2012 at 11:49 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Jul 6, 2012 3:16 PM, Per Bothner per.both...@oracle.com wrote:
On 07/06/2012 02:02 PM, Ryosuke Niwa wrote:
On Fri, Jul 6, 2012 at 12:54 PM, Per
On Wed, Jul 11, 2012 at 4:21 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Jul 11, 2012 at 6:54 AM, John Mellor joh...@chromium.org wrote:
Even obvious (to some) concepts like InlineBox have subtleties, for
example not all inline-level elements have inline boxes. An unambiguous
On Wed, Jul 11, 2012 at 8:43 AM, John Mellor joh...@chromium.org wrote:
On Wed, Jul 11, 2012 at 4:21 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Jul 11, 2012 at 6:54 AM, John Mellor joh...@chromium.org wrote:
Even obvious (to some) concepts like InlineBox have subtleties, for
example
On Jul 11, 2012 8:43 AM, John Mellor joh...@chromium.org wrote:
On Wed, Jul 11, 2012 at 4:21 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Jul 11, 2012 at 6:54 AM, John Mellor joh...@chromium.org wrote:
Even obvious (to some) concepts like InlineBox have subtleties, for
example not all
[(dev time of maintaining comments) + (risk of outdated comments causing
bugs X dev time of fixing resulting bugs)] (dev time gained by more
contributors each being more knowledgable)
No?
On Wed, Jul 11, 2012 at 8:53 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Jul 11, 2012 8:43 AM, John
On Wed, Jul 11, 2012 at 9:30 AM, Yaar Schnitman y...@chromium.org wrote:
[(dev time of maintaining comments) + (risk of outdated comments causing
bugs X dev time of fixing resulting bugs)] (dev time gained by more
contributors each being more knowledgable)
No?
How did you reach such a
On Wed, Jul 11, 2012 at 9:51 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Jul 11, 2012 at 9:30 AM, Yaar Schnitman y...@chromium.org wrote:
[(dev time of maintaining comments) + (risk of outdated comments causing
bugs X dev time of fixing resulting bugs)] (dev time gained by more
On 07/11/2012 09:30 AM, Yaar Schnitman wrote:
[(dev time of maintaining comments) + (risk of outdated comments causing
bugs X dev time of fixing resulting bugs)] (dev time gained by more
contributors each being more knowledgable)
No?
Perhaps:
[(dev time of maintaining comments)
+ (risk of
On Wed, Jul 11, 2012 at 10:44 AM, Adam Klein ad...@chromium.org wrote:
On Wed, Jul 11, 2012 at 9:51 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Jul 11, 2012 at 9:30 AM, Yaar Schnitman y...@chromium.org
wrote:
[(dev time of maintaining comments) + (risk of outdated comments causing
I think we've resolved our differences around the fixed position scrolling
issues, so that's OK.
Simon
On Jun 27, 2012, at 6:38 PM, Adam Barth aba...@webkit.org wrote:
There seems to be some amount of controversy at the moment regarding
how we should implement scrolling and fixed position
Yes. Thanks for holding off for a bit. :)
Adam
On Wed, Jul 11, 2012 at 11:03 AM, Simon Fraser simon.fra...@apple.comwrote:
I think we've resolved our differences around the fixed position scrolling
issues, so that's OK.
Simon
On Jun 27, 2012, at 6:38 PM, Adam Barth aba...@webkit.org
If you're just looking to draw a border, will the focus rings mechanism
suffice?
On Tue, Jul 10, 2012 at 1:37 AM, Patrick East patri...@bsquare.com wrote:
Hello,
We are working on a custom build of WebKit that will highlight a frame
when the mouse moves over it (the intent is to have it
Bear Travis, Alexandru Chiculita, and I have been working on the WebKit CSS
Exclusions implementation. I've been working on a set of C++ classes that are
used to compute the layout of inline content around or within exclusion shapes.
When I got started, before attempting to integrate the
On Wed, Jul 11, 2012 at 2:23 PM, Hans Muller hmul...@adobe.com wrote:
Have the merits of C++ unit tests been debated before? I noticed that a bug
representing as much has been around since 2008
(https://bugs.webkit.org/show_bug.cgi?id=21010). The last comment (2009)
concludes with: I'd be
Don't we have gunit tests in Tools/TestWebKitAPI already?
From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org]
on behalf of Hans Muller [hmul...@adobe.com]
Sent: Wednesday, July 11, 2012 5:23 PM
To: webkit-dev
Subject:
On 2012-07-10, at 16:24, Mark Rowe mr...@apple.com wrote:
I'm open to feedback on this proposal, but I'd like to move forward with this
change in the next day or two if no one objects.
Given the lack of outcry I've posted patches on
https://bugs.webkit.org/show_bug.cgi?id=91015 that make
I'm gonna chime in here, as I am 3 months into working on WebKit and the
lack of comments has driven me absolutely crazy. This is a bit of a rant
from a self-declared newbie, but I'm trying to be constructive. I've
contributed to a handful of open and closed source projects. I am trying to
help,
It looks like Tools/TestWebKitAPI/Tests/WebCore just contains one small
KURL test. I could certainly add more for the Exclusions shape classes,
but I got that feeling that maybe you get about being the first to take a
table at an empty restaurant. Perhaps it's just that most of the C++
classes in
Generally speaking, WebKit's testing philosophy is to test at API
boundaries, typically either a given port's WebKit API or the web platform
API. The benefit of that approach is that it makes it easier for us to
refactor the internals of WebCore without being constrained by fragile
tests---only
Thanks for the thoughtful reply. It was exactly the community's conventions
and customs that I was trying to get a handle on. Not to put too fine a
point on it, but I assume that adding unit tests to TestWebKitAPI or writing
tests that depend on APIs defined in Internals.idl wouldn't be
On Wed, Jul 11, 2012 at 4:31 PM, Hans Muller hmul...@adobe.com wrote:
Thanks for the thoughtful reply. It was exactly the community's
conventions and customs that I was trying to get a handle on. Not to put
too fine a point on it, but I assume that adding unit tests to
TestWebKitAPI or
(Resending from the right address)
FYI, Chromium port has some unit-like tests:
http://trac.webkit.org/browser/trunk/Source/WebKit/chromium/tests
Apparently it is not community's responsibility to maintain these. But it
might be useful for developing some low-level standalone/low-level stuff
I file a bug to extract a client interface for register protocol handler from
ChromeClient.
- Bug 90940 - Add ProtocolHandlerClient.h to the Modules/protocolhandler
(https://bugs.webkit.org/show_bug.cgi?id=90940)
In order to support this, the client needs to be supplementable first. I'm
Tony brought me in to comment on what impact this might have on the
Chromium Mac build. It shouldn’t have any impact. Any use of the
compiler-defined macros is fine.
In Chrome code, we usually use MAC_OS_X_VERSION_MAX_ALLOWED and
MAC_OS_X_VERSION_MIN_REQUIRED from AvailabilityMacros.h, along with
On 2012-07-11, at 17:46, Mark Mentovai m...@chromium.org wrote:
Tony brought me in to comment on what impact this might have on the Chromium
Mac build. It shouldn’t have any impact. Any use of the compiler-defined
macros is fine.
I agree. The only impact I expect this to have is if I've
Mark Rowe wrote:
TN2064 appears to have been last modified in 2003, so it predates the
existence of Availability.h.
Well, that’s about as long as I’ve been writing SDK- and
deployment-target-aware code…
Availability.h was introduced with the iOS SDK in order to support
availability macros
27 matches
Mail list logo
