On Mon, Aug 16, 2010 at 9:43 PM, Dean Jackson d...@apple.com wrote:
It was suggested I bring this to webkit-dev.
There was some recent work to move the many parameters passed to the Page
constructor into a single PageClients structure. The current assumption is
that if a feature is enabled
On Aug 16, 2010, at 10:52 PM, Eric Seidel wrote:
Where-ever it goes, please don't put it on Document directly. :)
(Feel free to tie it to Document's lifetime, just don't add to
Document's 300+ methods.)
The madness must stop... Document is long overdue for some weightloss...
I assume
On Aug 16, 2010, at 10:58 PM, Eric Zhou wrote:
Hi all,
following is the related code. My question is why it returns false when
ScheduledRedirection.type is redirection.
From the name of the function, I think if the url changes, it should return
true. Thus, for most of redirection, it
Hi Daniel,
Qt EWS should always report the stdout (and stderr) when the build
fails. If you see red Qt status bubble and empty result, please write
an e-mail with bug number to webkit-ews at sed.inf.u-szeged.hu ,
and we will try to find what the problem is.
I agree with you in MSVC issue,
Wouldn't it be easier to allow null clients than to have these EmptyClient
implementations?
Dean
I think that'd be a lot of null checks. It seems like it could add a fair bit
of code throughout WebCore, and folks would have to be careful not to forget
any null checks.
EmptyClients
On 16/08/2010, at 11:35 PM, Darin Fisher wrote:
Wouldn't it be easier to allow null clients than to have these EmptyClient
implementations?
Dean
I think that'd be a lot of null checks. It seems like it could add a fair
bit of code throughout WebCore, and folks would have to be
On 17/08/2010, at 12:22 AM, Maciej Stachowiak wrote:
On Aug 16, 2010, at 10:52 PM, Eric Seidel wrote:
Where-ever it goes, please don't put it on Document directly. :)
(Feel free to tie it to Document's lifetime, just don't add to
Document's 300+ methods.)
The madness must stop...
On 06/17/2010 02:30 AM, Anders Carlsson wrote:
Hi everyone,
We've now reached the point in WebKit2 development where we need to be able
to override some global calls in WebCore so that we can funnel them through
to another process, in a similar way to what Chromium does. We also need to
On 17/08/2010, at 7:21 AM, Eric Seidel wrote:
My apologies for derailing your earlier discussion. I just was in
Document.cpp again yesterday and my mind was blown by the madness that
is that god-class. Then you posted about adding to Document (which
sounds like the right corse of action
Hi all,
After a mini-b*tchfest on #webkit, Eric suggested I take it to the
mailing lists :)
It seems that we have this annoying little diff thrashing around in
WebCore/WebCore.xcodeproj/project.pbxproj:
http://trac.webkit.org/changeset/65520/trunk/WebCore/WebCore.xcodeproj/project.pbxproj
It’s the Xcode team’s fault, caused by people using different versions of
Xcode. Short term, I don’t know any way to make it go away. Long term it will
disappear once all contributors are using Xcode 3.2.3 or newer.
-- Darin
___
webkit-dev
Just a thought. Would it be too aggressive/premature to add a style rule
requiring the Xcode 3.2.3+ behavior? That would unfortunately mean that
users of older versions would have to manually edit the file to keep the
style checker happy.
On Tue, Aug 17, 2010 at 11:28 AM, Darin Adler
Actually, this is caused by Xcode 4 (still in beta).
See rdar://problem/8295614 Xcode 4 fights with Xcode 3 over developmentRegion
-Jeff
On Aug 17, 2010, at 1:28 PM, Darin Adler wrote:
It’s the Xcode team’s fault, caused by people using different versions of
Xcode. Short term, I don’t know
I think the check-webkit-style rule for whatever the dominant case is
makes a lot of sense.
-eric
On Tue, Aug 17, 2010 at 1:41 PM, Jeff Johnson
opendar...@lapcatsoftware.com wrote:
Actually, this is caused by Xcode 4 (still in beta).
See rdar://problem/8295614 Xcode 4 fights with Xcode 3 over
In that case, can we please standardize on the Xcode 3 behavior and ask
those using the beta to keep it out manually?
J
On Tue, Aug 17, 2010 at 7:41 PM, Jeff Johnson opendar...@lapcatsoftware.com
wrote:
Actually, this is caused by Xcode 4 (still in beta).
See rdar://problem/8295614 Xcode 4
On Aug 17, 2010, at 6:50 AM, Dean Jackson wrote:
On 17/08/2010, at 12:22 AM, Maciej Stachowiak wrote:
On Aug 16, 2010, at 10:52 PM, Eric Seidel wrote:
Where-ever it goes, please don't put it on Document directly. :)
(Feel free to tie it to Document's lifetime, just don't add to
On Aug 17, 2010, at 11:56 AM, Jeremy Orlow wrote:
In that case, can we please standardize on the Xcode 3 behavior and ask those
using the beta to keep it out manually?
(Not to pick on you Jeremy, you’re just the last one in the thread.)
Standardizing seems a little heavy handed. We’ve
On Aug 17, 2010, at 9:35 AM, Eric Seidel wrote:
My theory on re-organizing document is we do the same thing we've been
doing to FrameLoader. Just start lopping off chunks.
My understanding is Adam was attacking FrameLoader by just grabbing a
set of seemingly related member variables,
That's not always true, is it? Window at least used to have its API
spread across many classes (including frame, and at least 2 window
classes).
Document's API is a beast.
http://trac.webkit.org/browser/trunk/WebCore/dom/Document.idl
We can call the thing which has all the Document DOM API
I've had two WebCore full rebuilds today which currently I believe
were caused by this diff. (If that's true, then that too is an XCode
bug.) I have inconclusive evidence however, and will continue to test
and report back.
-eric
On Tue, Aug 17, 2010 at 2:00 PM, Darin Adler da...@apple.com
No, it's also added by versions of Xcode 3.x (some of which may not have been
released yet).
Simon
On Aug 17, 2010, at 11:41 AM, Jeff Johnson wrote:
Actually, this is caused by Xcode 4 (still in beta).
See rdar://problem/8295614 Xcode 4 fights with Xcode 3 over developmentRegion
I'm getting the same failure in two clients, and the second has
nothing checked out.
This is on OSX 10.5.8, using the standard webkit build scripts and
code synced yesterday [several times, same error]. Given that I don't
hear anyone else screaming, there's probably something wrong with my
On Aug 17, 2010, at 1:42 PM, Eric Uhrhane wrote:
I'm getting the same failure in two clients, and the second has
nothing checked out.
This is on OSX 10.5.8, using the standard webkit build scripts and
code synced yesterday [several times, same error]. Given that I don't
hear anyone else
On Aug 17, 2010, at 12:11 PM, Eric Seidel wrote:
Window at least used to have its API spread across many classes (including
frame, and at least 2 window
classes).
That is a historical anomaly. Some classes like Window used to be implemented
in the bindings layer. That was a bad idea, mixing
On Tue, Aug 17, 2010 at 2:00 PM, Chris Marrin cmar...@apple.com wrote:
On Aug 17, 2010, at 1:42 PM, Eric Uhrhane wrote:
I'm getting the same failure in two clients, and the second has
nothing checked out.
This is on OSX 10.5.8, using the standard webkit build scripts and
code synced
On Mon, Aug 16, 2010 at 7:49 PM, Maciej Stachowiak m...@apple.com wrote:
On Aug 13, 2010, at 9:59 AM, Mihai Parparita wrote:
On Fri, Aug 13, 2010 at 12:42 AM, Maciej Stachowiak m...@apple.com wrote:
1) It means the access control goes in fewer places - we don't have to have
access control on
On Aug 17, 2010, at 3:24 PM, Eric Uhrhane wrote:
On Tue, Aug 17, 2010 at 2:00 PM, Chris Marrin cmar...@apple.com wrote:
On Aug 17, 2010, at 1:42 PM, Eric Uhrhane wrote:
I'm getting the same failure in two clients, and the second has
nothing checked out.
This is on OSX 10.5.8, using the
Indeed, my copy of build-webkit was out of date on both clients, and I
don't know why. A manual svn update on that file brought down the
new version. Thanks for the help!
On Tue, Aug 17, 2010 at 3:37 PM, Chris Marrin cmar...@apple.com wrote:
On Aug 17, 2010, at 3:24 PM, Eric Uhrhane wrote:
Hi all,
I want to use C to operate DOM tree. Does it means I want to binding C to DOM
tree? I find that in the folder of webcore\bindings, there are some folders,
like js, objc.
In my opinion, the purpose of folders is binding the js or objc to DOM tree
,then it could operate DOM tree. So, if
29 matches
Mail list logo
