Re: [webkit-dev] Compiling WebKit up to 25% faster in Windows?

On Tue, Mar 26, 2013 at 5:51 PM, Benjamin Poulain wrote: > Hackabilty is a project goal. Compile time is not. > Well, in fairness, I think anyone contributing seriously to a codebase will get more hacking done if they're spending significantly less time recompiling :). I happen to be someone who

Re: [webkit-dev] Please don't leave entries for rebaseline in TestExpectation files

On Wed, Mar 20, 2013 at 11:46 PM, Robert Hogan wrote: > On Wednesday, 20 March 2013, Ryosuke Niwa wrote: > >> Please don't add lines to TestExpectations saying that they just need >> rebaselines and then leave. >> > > OK. That means I will have to pull the new results from the bots, which is > fin

Re: [webkit-dev] Overtype mode in WebKit for editable content?

On Mon, Mar 11, 2013 at 8:54 PM, Shezan Baig wrote: > I feel like I should give some background to this discussion. > Thanks for this context. It's helpful. So I guess the question boils down to something like: if we have > changes that are generally useful, but not used in the major WebKit >

Re: [webkit-dev] Overtype mode in WebKit for editable content?

On Mon, Mar 11, 2013 at 7:01 PM, Ryosuke Niwa wrote: > Yes, we should disable triple-click-to-select-all on Windows > You realize that Wordpad, Word, and Internet Explorer all support this, though, right? My point was not just to raise a behavior that seems like a clear win, it was to reiterate

Re: [webkit-dev] Overtype mode in WebKit for editable content?

On Mon, Mar 11, 2013 at 5:54 PM, Ryosuke Niwa wrote: > Having said that, I object to implementing a behavior doesn't match > "RichEdit" or "Edit" window classes on Windows. We should match either > native edit window class. > Are you referring to my comments about the cursor? Do you object, the

Re: [webkit-dev] Overtype mode in WebKit for editable content?

On Mon, Mar 11, 2013 at 5:11 PM, Ryosuke Niwa wrote: > Of course, each application can implement overtype in "Edit" window class > and manually disable it in "RichEdit" window class but I don't think that's > an interesting fact since that's a customization. An application doesn't > even have to

Re: [webkit-dev] Overtype mode in WebKit for editable content?

On Mon, Mar 11, 2013 at 4:21 PM, Ryosuke Niwa wrote: > On Mon, Mar 11, 2013 at 3:56 PM, Peter Kasting wrote: > >> On Mon, Mar 11, 2013 at 2:59 PM, Ryosuke Niwa wrote: >> >>> Is it expected that overtype works on Windows or on Linux? e.g. If >>> "Edit&qu

Re: [webkit-dev] Overtype mode in WebKit for editable content?

On Mon, Mar 11, 2013 at 2:59 PM, Ryosuke Niwa wrote: > Is it expected that overtype works on Windows or on Linux? e.g. If "Edit" > and "RichEdit" window classes both support this feature natively on Windows > (which I bet they do), then the answer is yes. > The non-rich edit control on Windows (

Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)

On Sat, Feb 9, 2013 at 11:52 AM, Maciej Stachowiak wrote: > There are certainly pros and cons to merging. It would be great get input > from the broader WebKit community on the tradeoff of merging sooner vs > avoidance of weird legacy code in the main tree. In the meantime, we'll > stick to mergi

Re: [webkit-dev] Int/FloatPoint and Int/FloatSize

On Thu, Jan 3, 2013 at 11:36 AM, Shawn Singh wrote: > Cons of making a separate vector class: > - "offsets" are sometimes treated as relative point locations, and other > times treated as vectors that can be added to points. Deciding when to use > which one could become just as confusing as usi

Re: [webkit-dev] Int/FloatPoint and Int/FloatSize

On Wed, Jan 2, 2013 at 11:21 PM, Steve Block wrote: > - Would people welcome changes to encourage that policy? FWIW, in Chromium (downstream, non-WebKit) we ended up adding a "vector" (as in math, not the STL) class recently to address the sort of "offset/delta between two points" use you're des

Re: [webkit-dev] Please avoid rolling out patches speculatively and reland them ASAP if you had to

On Tue, Dec 11, 2012 at 2:20 PM, Oliver Hunt wrote: > Or the sheriff could actually see if rolling out a patch locally fixes the > problem. I'm not sure why they're considering "not testing" to be a valid > behaviour for someone who is ostensibly meant to be keeping things going in > the face of

Re: [webkit-dev] Please avoid rolling out patches speculatively and reland them ASAP if you had to

On Tue, Dec 11, 2012 at 2:14 PM, Oliver Hunt wrote: > I don't understand why anyone is _speculatively_ rolling out patches. > > You should only be rolling it out if you _know_ the patch is bad. > Sometimes something bad happens to the tree, the sheriff doesn't know which patch is responsible, an

Re: [webkit-dev] Please avoid rolling out patches speculatively and reland them ASAP if you had to

On Tue, Dec 11, 2012 at 1:19 PM, Emil A Eklund wrote: > > I don't understand your logic. A patch landed, the sheriff thinks maybe > it > > was bad and rolls it out, then it turns out it was a red herring. Why > is it > > not now the sheriff's responsibility to re-land? After all, the patch > w

Re: [webkit-dev] Please avoid rolling out patches speculatively and reland them ASAP if you had to

On Tue, Dec 11, 2012 at 1:11 PM, Emil A Eklund wrote: > > That said, if your strong reason turned out to be incorrect, you should > recommit the patch, no? > > That seems like a bad idea, someone that understands the patch should > recommit it. Ideally the original author. I don't understand yo

Re: [webkit-dev] moving focus when clicking on scrollbars

It seems worth noting over here that on the whatwg discussion for this, "native" really means "Mac and Ubuntu". Notably it's not clear whether this matches Windows, which is 90+% of the userbase for Chrome. I am a little nervous making blanket statements like "this is native behavior" when we're

Re: [webkit-dev] moving focus when clicking on scrollbars

On Wed, Oct 31, 2012 at 2:40 PM, Ojan Vafai wrote: > On Wed, Oct 31, 2012 at 2:29 PM, Peter Kasting wrote: > >> Is there rationale for Gecko's behavior? It sounds a bit strange. >> > > Not that I know of. I haven't talked to anyone at Gecko about it though

Re: [webkit-dev] moving focus when clicking on scrollbars

On Wed, Oct 31, 2012 at 1:32 PM, Ojan Vafai wrote: > Every native platform that has scrollbars does *not* move focus when you > click on them. Every browser engine, except Gecko, moves focus when you > click on scrollbars *unless* you're clicking on the viewport scrollbar > (e.g. clicking on the

Re: [webkit-dev] On returning mutable pointers from const methods

On Sun, Oct 28, 2012 at 11:16 PM, Maciej Stachowiak wrote: > On Oct 28, 2012, at 10:09 PM, Peter Kasting wrote: > > On Sun, Oct 28, 2012 at 6:12 AM, Maciej Stachowiak wrote: > >> I am not sure a blanket rule is correct. If the Foo* is logically related >> to the obje

Re: [webkit-dev] On returning mutable pointers from const methods

On Sun, Oct 28, 2012 at 3:12 PM, Filip Pizlo wrote: > The point is that a rule mandating const methods to return const pointers > prevents me from saying that getting a pointer from a container doesn't > change the container. > Um, yes, that's exactly the point. My argument was that it's very r

Re: [webkit-dev] On returning mutable pointers from const methods

On Sun, Oct 28, 2012 at 2:29 PM, Filip Pizlo wrote: > It is useful to say that "getting a pointer to T from an object of type S > does not change S's state". > That's pretty much the definition of physical constness. PK ___ webkit-dev mailing list web

Re: [webkit-dev] On returning mutable pointers from const methods

On Sun, Oct 28, 2012 at 6:12 AM, Maciej Stachowiak wrote: > I am not sure a blanket rule is correct. If the Foo* is logically related > to the object with the foo() method and effectively would give access to > mutable internal state, then what you say is definitely correct. But if the > const ob

Re: [webkit-dev] On returning mutable pointers from const methods

On Fri, Oct 26, 2012 at 8:27 AM, Rik Cabanier wrote: > It is valid for a const method to return you a new object ie a const > factory object. > In that case, const-ness would not be desired. > Not really. The point of this thread is that such functions may not modify an object's state themselve

Re: [webkit-dev] On returning mutable pointers from const methods

On Thu, Oct 25, 2012 at 3:48 AM, Andreas Kling wrote: > So, I propose that we allow only these two signature formats for raw > pointers: > > - const Foo* foo() const; > - Foo* foo(); > This was part of a discussion I had on this list (IIRC) a while back. The context was the larger issue of cons

Re: [webkit-dev] A proposal for handling "failing" layout tests and TestExpectations

On Wed, Aug 15, 2012 at 6:02 PM, Filip Pizlo wrote: > 2) Possibility of the sheriff getting it wrong. > > (2) concerns me most. We're talking about using filenames to serve as a > kind of unchecked comment. We already know that comments are usually bad > because there is no protection against t

Re: [webkit-dev] A proposal for handling "failing" layout tests and TestExpectations

On Wed, Aug 15, 2012 at 5:45 PM, Filip Pizlo wrote: > The typical approach used in situations that you describe is to rebase, > not skip. > Which is precisely what Dirk is proposing. Literally the only difference here is that the rebased test expectation would contain an optional notation about

Re: [webkit-dev] A proposal for handling "failing" layout tests and TestExpectations

On Wed, Aug 15, 2012 at 5:00 PM, Filip Pizlo wrote: > I believe that the cognitive load is greater than any benefit from > catching bugs incidentally by continuing to run a (1-fail) or (3) test, and > continuing to evaluate whether or not the expectation matches some notions > of desired behavior

Re: [webkit-dev] Status of multithreaded image decoding

On Sun, Aug 12, 2012 at 1:24 PM, Maciej Stachowiak wrote: > Why not start asynchronous decoding immediately as the image is loading, > and synchronize at paint time? What is the benefit of waiting until layout > time to start decoding the image data? > Uninformed guess (since I haven't touched t

Re: [webkit-dev] trac.webkit.org timeline broken

It looks like the timeline has once again stopped updating. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] trac.webkit.org timeline broken

The Trac timeline doesn't seem to have updated since last night. It's missing about 15 commits right now. Trying to link to one of these -- e.g. http://trac.webkit.org/changeset/123971 -- doesn't work. Not sure to whom to direct this problem. PK ___ w

Re: [webkit-dev] PSA: rebaseline tooling

On Thu, Jul 12, 2012 at 4:16 PM, Dirk Pranke wrote: > At the top of the garden-o-matic page there is a line like "Latest > revision processed by every bot: 122499 (trunk is at 122524)". I think > that does what you want? Ah, I hadn't noticed that. That sounds promising! PK ___

Re: [webkit-dev] PSA: rebaseline tooling

On Thu, Jul 12, 2012 at 3:17 PM, Ojan Vafai wrote: > https://trac.webkit.org/wiki/Rebaseline > > I've recently consolidated the various rebaseline commands and made the > tool work for non-Chromium ports. > > I especially like "webkit-patch rebaseline > path/to/test/i/just/broke.html", which lets

Re: [webkit-dev] TestExpectations syntax changes, last call (for a while, at least) ...

On Thu, Jun 14, 2012 at 1:39 PM, Elliot Poger wrote: > Can someone please remind me why IMAGE+TEXT even exists? > > Wouldn't it be simpler to just mark a test as follows? > >- IMAGE : allow image failure; go red if there is a text failure >- TEXT: allow text failure; go red if there is an

Re: [webkit-dev] TestExpectations syntax changes, last call (for a while, at least) ...

On Wed, Jun 13, 2012 at 5:49 PM, Dirk Pranke wrote: > Anyone not okay with: > > webkit.org/12345 [Win Mac Debug] > animations/stop-animation-on-suspend.html [Crash Text Pass] > I withdraw my objections to this in the hopes of getting _some_ kind of consensus and moving on with our lives :) PK _

Re: [webkit-dev] TestExpectations syntax changes, last call (for a while, at least) ...

On Wed, Jun 13, 2012 at 3:58 PM, Darin Adler wrote: > On Jun 13, 2012, at 3:53 PM, Dirk Pranke wrote: > > * we use "\" (backslash) as a delimiter instead of ":" and "=" > > Seems worse to me. When I see a backslash I assume it’s a line > continuation character or a C escape sequence. > Gotta a

Re: [webkit-dev] Rename FAIL to DIFF Was (Re: PSA: FAIL test expectation does not encompass MISSING, CRASH, or TIMEOUT)

On Thu, Jun 7, 2012 at 12:33 PM, Ryosuke Niwa wrote: > Not if the test was padding. I'm talking about the case where you're > modifying WebCore and know that some tests are going to need rebaselines. > People have advised in the past that patch authors add failing test > expectations to TestExpec

Re: [webkit-dev] Rename FAIL to DIFF Was (Re: PSA: FAIL test expectation does not encompass MISSING, CRASH, or TIMEOUT)

On Wed, Jun 6, 2012 at 11:28 PM, Ryosuke Niwa wrote: > > I don't think DIFF is any better. It sounds like it means the output is > "different than what we wanted", thus it effectively means "didn't pass", > and one would expect it to match MISSING/CRASH/TIMEOUT as much as one would > expect FAIL

Re: [webkit-dev] Rename FAIL to DIFF Was (Re: PSA: FAIL test expectation does not encompass MISSING, CRASH, or TIMEOUT)

On Wed, Jun 6, 2012 at 10:22 PM, Ryosuke Niwa wrote: > Now that everyone knows the problem, I propose to rename FAIL to DIFF. > > FAIL should mean that the test fails, not that it fails with image, text, > or image and text failures. > > DIFF, on the other hand, has no ambiguity. It can't be inte

Re: [webkit-dev] Simplifying syntax in test_expectations.txt (bug 86691)

On Thu, May 17, 2012 at 2:11 PM, Ojan Vafai wrote: > Oh, I supposed I misread Peter's earlier email as being opposed to this. > You didn't misread me. I have the same opinion as you: this would be a change for the worse. PK ___ webkit-dev mailing lis

Re: [webkit-dev] Simplifying syntax in test_expectations.txt (bug 86691)

On Thu, May 17, 2012 at 1:34 PM, Ojan Vafai wrote: > 2. Make outcomes optional. If they are left out, then the test is skipped > (unless the test is marked SLOW, in which case it's expected to pass). > There is no SKIP modifier. > I don't think we should do this. It seems very subtle. I'd rath

Re: [webkit-dev] Simplifying syntax in test_expectations.txt (bug 86691)

On Thu, May 17, 2012 at 12:19 PM, Ryosuke Niwa wrote: > On Thu, May 17, 2012 at 11:54 AM, Maciej Stachowiak wrote: >> >> Perhaps aligning the fields column after the bug URL would improve >> readability (though it makes things a little harder to edit): >> >> We certainly could. We treat \s+ as \

Re: [webkit-dev] Using namespace std

On Thu, May 17, 2012 at 12:02 PM, Ryosuke Niwa wrote: > It appears to me using fully qualified names (e.g. std::max(~) at call > site) is far superior to using directive for individual symbols (e.g. using > std::max). > It sounds in general like a number of people have been in favor of this, and

Re: [webkit-dev] Simplifying syntax in test_expectations.txt (bug 86691)

On Thu, May 17, 2012 at 9:26 AM, Dimitri Glazkov wrote: > I actually quite like > the clear delineation between test modifiers and test expectations. Me too. Please please please leave them on opposite sides. All these proposals that try to put them both before the test name are much harder fo

Re: [webkit-dev] Using namespace std

On Tue, May 15, 2012 at 11:37 AM, Ryosuke Niwa wrote: > On May 15, 2012 10:53 AM, "Peter Kasting" wrote: > > Given how little of std:: we actually use (since WTF is used instead for > most things), what about just explicitly qualifying usages with std:: > directly?

Re: [webkit-dev] Using namespace std

On Tue, May 15, 2012 at 9:31 AM, Darin Adler wrote: > On May 15, 2012, at 5:48 AM, Allan Sandfeld Jensen wrote: > > > To me it seems like an odd practice, so I would like to ask what > original rationale behind that style guideline is > > Adding a list of using declarations like "using std::min"

Re: [webkit-dev] Bash scripts should support LF endings only

On Fri, Feb 24, 2012 at 11:13 AM, Ashod Nakashian wrote: > In short, the issue is that some bash scripts have their svn:eol-style set > to native, which is CRLF on Windows. This is causing build failures on some > version of cygwin-bash that don't like CR in the scripts. > I fixed a number of the

Re: [webkit-dev] Top 100 sites browsing tests proprosal

On Sun, Jan 22, 2012 at 11:55 AM, Balazs Kelemen wrote: > As the goal is to test "real world" use case I think it can be even better > to simply load the sites from network. > I see only two disadvantage of that but neither of them are blocker: >1. The sites changing over time. However, as th

Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)

On Mon, Dec 5, 2011 at 5:22 PM, Geoffrey Garen wrote: > > We're creating a branch in order to demonstrate that it's useful and > that it does not negatively impact hackability or performance. > > It hadn't occurred to me to view the goals of the WebKit project as > applying only to trunk, and not

Re: [webkit-dev] Using C++ constant pointers (type_name * const) in WebKit

On Mon, Nov 28, 2011 at 1:38 PM, David Kilzer wrote: > In a discussion on Bug 71921, > Antti, Darin Adler and I started a discussion about using C++ constant > pointers in WebKit. Does the WebKit community have a consensus opinion on > the matter? >

Re: [webkit-dev] Reg. New File Inclusion Style for Webkit

On Sun, Nov 20, 2011 at 1:57 AM, Arunprasad Rajkumar wrote: > Why don't we follow chrome style of file inclusions rather than the usual. > > For example, > *#include "WebCore/Page/Chrome.h"* > > This will be more convient way of representing the inclusion. Hope it will > avoid long compiler inclu

Re: [webkit-dev] Cleaning up directories in WebCore

On Fri, Nov 18, 2011 at 2:38 PM, Ryosuke Niwa wrote: > On Fri, Nov 18, 2011 at 2:27 PM, Adam Barth wrote: > >> We move files around all the time. If we're afraid to move files for >> these reasons, we'll be stuck with bad organizational choices we made >> in the distant past. WebKit's philosop

Re: [webkit-dev] It's time to remove the Haiku port

On Thu, Nov 3, 2011 at 7:32 PM, Ryan Leavengood wrote: > The primary problem with our port right now is some of the developers > made the choice (which I objected to) to make our own Subversion repo > containing the WebKit code to make it easier (in their eyes) to > develop the port. > > Where can

Re: [webkit-dev] Gamepad API [Was: New feature flag proposal: Joystick API]

On Wed, Oct 12, 2011 at 3:58 PM, Alexey Proskuryakov wrote: > Quoting what I actually said in the bug, "I don't think that we should > accept an implementation of a spec that's so immature that it doesn't even > have a meaningful name." > That the name is not meaningful, and that this is a sign

Re: [webkit-dev] New feature flag proposal: Joystick API

On Thu, Oct 6, 2011 at 1:42 PM, Alexey Proskuryakov wrote: > > 06.10.2011, в 13:23, Peter Kasting написал(а): > > Why are you convinced there is input device fragmentation here? My > understanding is that the spec as proposed already handles multi-axis > digital and analog

Re: [webkit-dev] New feature flag proposal: Joystick API

On Thu, Oct 6, 2011 at 11:50 AM, Alexey Proskuryakov wrote: > I don't want to take a particularly strong stance against Joystick/Gamepad > specifically, but I see codifying input device fragmentation in Web specs > and APIs as a move in a wrong direction. > Why are you convinced there is input d

Re: [webkit-dev] Change to style guideline: should use type& instead of type* for out arguments

On Tue, Oct 4, 2011 at 2:06 PM, Ryosuke Niwa wrote: > In my understanding, we use pass by reference for out arguments when they > have to be modified in callees. > I had not heard this. Personally I weakly prefer pointers to non-const refs for outparams, but if there is convention the other way

Re: [webkit-dev] Fastest image format

On Tue, Oct 4, 2011 at 2:22 AM, Joe LaFritte wrote: > What is the fastest image format for wekbit ? I mean which image format > (jpg, png, gif, etc.) is decoded and displayed fastest than the other ones > ? > That likely depends on the image, the decoder, and the system in question. For example

Re: [webkit-dev] Mouse Lock API

On Wed, Sep 21, 2011 at 12:05 PM, Alexey Proskuryakov wrote: > Anyway, I'm not sure if we already agreed that mouse lock is only desirable > in full screen. I think that the spec has the goal of enabling it in browser > windows. > Indeed, this is explicitly a use case we want to allow. It's rea

Re: [webkit-dev] Color profiles in expected.png files

On Fri, Sep 9, 2011 at 7:21 PM, Simon Fraser wrote: > I think we should be consistent about color profiles, and in a way that > doesn't break pixel tests. Does anyone want to vote one way or the other? I suspect "no profiles" is the only way that will work across both ports that handle embedded

Re: [webkit-dev] Committing EFL baselines

On Mon, Sep 12, 2011 at 1:56 PM, David Levin wrote: > On Mon, Sep 12, 2011 at 1:48 PM, Peter Kasting wrote: > >> In particular, if we have pixel tests that don't need to be pixel tests at >> all, or font rendering differences due to explanatory text that could be >

Re: [webkit-dev] Committing EFL baselines

On Mon, Sep 12, 2011 at 1:36 PM, Ryosuke Niwa wrote: > This is pretty much unreviewable, so I pretend to commit this directly, in >> batches (one commit per toplevel directory in LayoutTests/platform/efl) in >> the next weeks. Any objections or suggestions? >> > > It'll be nice if we could spend

Re: [webkit-dev] Building Chromium port of WebKit on Windows

On Thu, Aug 25, 2011 at 10:31 AM, Dimitri Glazkov wrote: > FWIW, I use the former exclusively on Mac. > Yes, please regard my comments as only applying to Windows. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailm

Re: [webkit-dev] Building Chromium port of WebKit on Windows

On Thu, Aug 25, 2011 at 10:07 AM, Mikhail Naganov wrote: > I'm not sure we are on the same page. I'm talking about Chromium port > of WebKit, where Chromium checkout is _inside_ WebKit's > Source/WebKit/chromium, as opposed to when you have full WebKit > checkout inside Chromium's third_party. Y

Re: [webkit-dev] Building Chromium port of WebKit on Windows

The way I make this work is to set up a full Chromium checkout with a trunk (rather than DEPS-controlled) WebKit checkout. (There are some instructions for this in the Chromium developer pages.) Then I can use VS2008 to build and test whatever I want. And I use Cygwin. I don't know much about t

Re: [webkit-dev] Switching away from integers for layout

On Thu, Jun 23, 2011 at 11:46 AM, Levi Weintraub wrote: > To address this we plan to convert the rendering tree to float to allow for > better zooming and scaling support. Furthermore this could be expanded to > support sub-pixel layout and positioning which in turn would allow higher > precision

Re: [webkit-dev] 194 bugs in pending-commit

On Fri, Jun 17, 2011 at 10:56 PM, Adam Barth wrote: > 2) Mark the patch as obsolete / clear the review flag if we're not > going to land the patch. Does the slash mean "do both"? I have https://bugs.webkit.org/show_bug.cgi?id=47036 on that list and the only r+ed patch on it is already marked o

Re: [webkit-dev] Do we have a style preference about const member functions?

On Thu, Jun 9, 2011 at 3:51 PM, Maciej Stachowiak wrote: > In principle, the return value could have been retrieved from a container > that the immediate callee only has a const reference to. So then casting > away const on the return value would be a hazard. > You're right; if the implementatio

Re: [webkit-dev] Do we have a style preference about const member functions?

On Thu, Jun 9, 2011 at 2:49 AM, Maciej Stachowiak wrote: > > I'm not really convinced that casting away const from a return value is > intrinsically safer than casting away const from "this". > Allowing the caller to mutate the return value is fine because the caller had a non-const |this| to beg

Re: [webkit-dev] Do we have a style preference about const member functions?

On Wed, Jun 8, 2011 at 11:59 AM, Darin Adler wrote: > On Jun 8, 2011, at 11:56 AM, Peter Kasting wrote: > > I'm perfectly happy removing "const" from accessors in the first > category. I can post a change that does that before going any further. > > Yes, I beli

Re: [webkit-dev] Do we have a style preference about const member functions?

On Wed, Jun 8, 2011 at 11:51 AM, Darin Adler wrote: > On Jun 8, 2011, at 11:48 AM, Peter Kasting wrote: > > On Tue, Jun 7, 2011 at 11:18 PM, Maciej Stachowiak > wrote: > >> 1) We definitely have consensus to fix the broken non-logically-const > accessors by making them

Re: [webkit-dev] Do we have a style preference about const member functions?

On Tue, Jun 7, 2011 at 11:18 PM, Maciej Stachowiak wrote: > 1) We definitely have consensus to fix the broken non-logically-const > accessors by making them non-const; consensus on also adding const accessors > is less clear. > There are a surprising number of places that actually do const trave

Re: [webkit-dev] Do we have a style preference about const member functions?

On Fri, Jun 3, 2011 at 5:59 PM, Darin Adler wrote: > On Jun 3, 2011, at 5:46 PM, Peter Kasting wrote: > > > From the perspective of Node itself, I'm not sure why this would be a > "big task". There shouldn't be any const accessors that return non-const >

Re: [webkit-dev] Do we have a style preference about const member functions?

On Fri, Jun 3, 2011 at 5:27 PM, Darin Adler wrote: > From a const Node* you can get: > >- a non-const pointer to a parent, sibling, or child >- a non-const pointer to the document >- a non-const pointer to the renderer >- a non-const pointer to the style >- a non-const pointer

Re: [webkit-dev] Do we have a style preference about const member functions?

On Thu, Jun 2, 2011 at 1:02 PM, Geoffrey Garen wrote: > Perhaps we could at least encourage const-correctness for newly-written > classes? By this I mean both adherence to the logical-constness rules you > stated earlier as well as not adding non-const accessors and members unless > needed -- oth

Re: [webkit-dev] Do we have a style preference about const member functions?

On Tue, May 31, 2011 at 11:31 PM, Maciej Stachowiak wrote: > The following would be valid but would require us to cast away const all > over the place and would therefore in my opinion be a net negative: > > const Node* previousSibling() const { return m_previous; } > > And what's in our code no

Re: [webkit-dev] Do we have a style preference about const member functions?

On Tue, May 31, 2011 at 11:00 AM, Maciej Stachowiak wrote: > I agree that const should be used for "logical constness". The rule should > not be merely "doesn't alter any data members of this object" but rather > "does not alter observable state of this object or vend any type of pointer > or ref

Re: [webkit-dev] Do we have a style preference about const member functions?

On Mon, May 30, 2011 at 11:32 PM, Maciej Stachowiak wrote: > A linked list node or tree node could useful have const methods, which give > only const pointers/references to other nodes. If there is a reason const > references to DOM nodes or renew objects are not useful, it is not due to > the ob

Re: [webkit-dev] Large Source Reorganizations By External WebKit Ports

On Thu, May 19, 2011 at 9:09 AM, Charles Pritchard wrote: > I think Brent's question to the list may have some merit if looked at from > a different perspective. > Let me try it... Peter: Are there any lessons learned about that process > Chromium went through? > Darin Fisher shared most of the

Re: [webkit-dev] Large Source Reorganizations By External WebKit Ports

On Wed, May 18, 2011 at 12:36 PM, Brent Fulgham wrote: > Google > used this same approach with their Chromium port, the side effects of > which find us in year two (or three?) of the effort to merge those > changes back into the core WebKit archive. > Um, what? The Chromium port is fully upstre

Re: [webkit-dev] New feature - MHTML support

On Mon, May 2, 2011 at 11:47 AM, Alexey Proskuryakov wrote: > Is this something that was requested by Chrome users? > There has definitely been interest from both consumers and enterprise on the Chrome side. PK ___ webkit-dev mailing list webkit-dev@l

Re: [webkit-dev] Platform LayoutTests are out of control

On Wed, Apr 20, 2011 at 10:46 PM, Ryosuke Niwa wrote: > On Wed, Apr 20, 2011 at 10:41 PM, Peter Kasting wrote: >> >> * Convert tests to reftests >> > > I don't think we should do this until all ports start using > new-run-webkit-tests on their bots. > It&#x

Re: [webkit-dev] Platform LayoutTests are out of control

Hi Brent, In a past thread, I noted that we could do a couple of things to reduce platform-specific results, and the overall size of layout test results. In order of increasing difficulty: * Convert pixel tests to dumpAsText tests when pixel output is unnecessary (merely requires adding a comman

Re: [webkit-dev] UA string changes blog draft

On Fri, Mar 25, 2011 at 1:08 PM, Peter Kasting wrote: > On Fri, Mar 25, 2011 at 1:03 PM, Mark Rowe wrote: > >> Safari 5.0.3 will always report a build version of 533.19.4. Safari 5.0.4 >> will always report a build version of 533.20.27. You already used the former >>

Re: [webkit-dev] UA string changes blog draft

On Fri, Mar 25, 2011 at 1:03 PM, Mark Rowe wrote: > On 2011-03-25, at 12:56, Peter Kasting wrote: > > On Fri, Mar 25, 2011 at 12:54 PM, Mark Rowe wrote: > >> Is there some reason why these examples use manufactured Safari build >> numbers? It's implausible that a v

Re: [webkit-dev] UA string changes blog draft

On Fri, Mar 25, 2011 at 12:54 PM, Mark Rowe wrote: > Is there some reason why these examples use manufactured Safari build > numbers? It's implausible that a version of Safari with a build number of > 534.24 would ever claim to be version 5.0.3. > Sorry, I wasn't sure what the right numbers wer

Re: [webkit-dev] UA string changes blog draft

On Fri, Mar 25, 2011 at 11:44 AM, Peter Kasting wrote: > I've incorporated all the existing feedback into the draft. Feel free to > take another look. Since some folks seem to be unable to see the draft even while logged in, here's the new fulltext. PK --- User Agent S

Re: [webkit-dev] UA string changes blog draft

On Fri, Mar 25, 2011 at 11:54 AM, David Levin wrote: > The blog post begs the question made me wonder. > > Why was "Macintosh; " kept when it is redundant with "Intel Mac OS X > 10_6_7"? > The reasoning seem analogous to what was given for why "Windows;" was > removed. > Unlike "Windows", the s

Re: [webkit-dev] UA string changes blog draft

I've incorporated all the existing feedback into the draft. Feel free to take another look. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] UA string changes blog draft

On Fri, Mar 25, 2011 at 11:05 AM, Patrick R. Gansterer wrote: > If you take a look at > http://trac.webkit.org/browser/trunk/Source/WebKit/wince/WebCoreSupport/FrameLoaderClientWinCE.cpp#L57I’m > not sure if point 5 is correct. ;-) > > The WinCE port has still my initial UA string for testing. >

Re: [webkit-dev] UA string changes blog draft

On Fri, Mar 25, 2011 at 10:50 AM, Peter Kasting wrote: > I've created a draft blog post at http://www.webkit.org/blog/?p=1580 about > the recent changes I and others have made to the UA string. I'm interested > in any feedback you might have. > Note, since this is a dra

[webkit-dev] UA string changes blog draft

Hello WebKit developers, I've created a draft blog post at http://www.webkit.org/blog/?p=1580 about the recent changes I and others have made to the UA string. I'm interested in any feedback you might have. I've written a similar blog post, but focused on Chrome and aimed at a wider audience, th

Re: [webkit-dev] Build system update

On Wed, Mar 23, 2011 at 2:08 PM, Adam Barth wrote: > Indeed. I suspect (2) and (3) are worth doing regardless. > AFAIK, gyp currently always regenerates everything and then compares the new versions to the old to see if it actually needs to touch the files on disk. This seems safe but slow. P

Re: [webkit-dev] Every build is crashing

On Tue, Feb 15, 2011 at 11:23 AM, Adam Barth wrote: > > This has been discussed on IRC when it started - everyone present seemed > to be OK with that, and didn't want to revert. Please feel free to revert, > of course. > > I must have missed that discussion. Maybe we should note these things > i

Re: [webkit-dev] Aligning User Agent Header changes

On Thu, Feb 10, 2011 at 7:32 AM, wrote: > QtWebKit is considering dropping the language tag part of the User Agent > string - following Firefox ( > http://hacks.mozilla.org/2010/09/final-user-agent-string-for-firefox-4/). > I think the WebKit community did a reasonable job at aligning the User Ag

Re: [webkit-dev] Web Inspector blog post draft

On Wed, Feb 9, 2011 at 4:32 AM, Alexander Pavlov wrote: > I have put together a Web Inspector blog post draft ( > http://webkit.org/blog/?p=1463) concerning the latest style editing > improvements. Please speak up if you think something should be changed, > added, or removed. > I get an error pag

Re: [webkit-dev] precompiled headers

My understanding is that it is supposed to be possible to build all ports without PCH support. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] coding style and comments

This thread has probably gone the way of all webkit-dev threads on comments or ChangeLog files -- people's opinions vary, it turns into a bikeshed, and nothing really changes about how we code. Repeat in a year. w.r.t. ImageDecoder specifically, as I mentioned before I do agree that there are som

Re: [webkit-dev] coding style and comments

On Mon, Jan 31, 2011 at 12:47 PM, Maciej Stachowiak wrote: > On Jan 31, 2011, at 11:01 AM, Peter Kasting wrote: > I think people who favor comments tend to produce a lot of exactly this > kind of comment. Except in some cases its verbose multiline comments that > exceed the numb

Re: [webkit-dev] Using Visual Studio 2010 for Apple's Windows WebKit port

On Mon, Jan 31, 2011 at 12:30 PM, Adam Roben wrote: > Please let me (and the list) know if this change will cause you trouble, > and if there's something we can do to make the transition easier. > This may make life hard on Chromium as right now we don't support building with VS2010. We are wor

Re: [webkit-dev] coding style and comments

On Sun, Jan 30, 2011 at 4:47 PM, Maciej Stachowiak wrote: > Well, I didn't mean to pick on the authors of this file. This is the > impression I get from a lot of code that some call "well-commented", by > which they mean "lots of comments". > I agree that the comments you pointed out are pretty

  1   2   3   4   >