[webkit-dev] Issue Analysis:48290 [HTML Canvas globalCompositeOperation]

Hi All, I was going through the bug https://bugs.webkit.org/show_bug.cgi?id=48290, which passes is FF but fails in Safari/Winlauncher( r87771). As per http://www.w3.org/TR/2011/WD-2dcontext-20110525/#compositing, "highlight" is NOT a valid composite operation. but it is being mentioned in platfor

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

On May 31, 2011, at 10:00 PM, Brent Fulgham wrote: > > On May 31, 2011, at 8:44 PM, Maciej Stachowiak wrote: > >> For example, the compiler does not tell you that the following >> implementation of Node::previousSibling() (currently in our code!) is >> totally wrong from the "logical const" p

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

On May 31, 2011, at 8:44 PM, Maciej Stachowiak wrote: > For example, the compiler does not tell you that the following implementation > of Node::previousSibling() (currently in our code!) is totally wrong from the > "logical const" perspective: > >Node* previousSibling() const { return m_p

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

On May 31, 2011, at 5:55 PM, Brent Fulgham wrote: > Hi, > > On Tue, May 31, 2011 at 4:37 PM, Maciej Stachowiak wrote: >> I agree that one useful distinction is whether a particular kind of object >> is every manipulated via const pointers or references. If we never use const >> references/point

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

Hi, On Tue, May 31, 2011 at 4:37 PM, Maciej Stachowiak wrote: > I agree that one useful distinction is whether a particular kind of object > is every manipulated via const pointers or references. If we never use const > references/pointers to a particular kind of object, then it is probably not >

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

On May 31, 2011, at 12:08 PM, Geoffrey Garen 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] Pages from the wiki vanished from google search results

Someone could check: https://www.google.com/webmasters I no longer have access (but I could go through the process of getting access if needed). -eric On Tue, May 31, 2011 at 1:37 PM, Ademar Reis wrote: > Hi there. > > Since a couple of days ago (when?), our trac/wiki is not appearing as > rele

[webkit-dev] WebKitGTK+ Lucid PPA now available

Hello fellow WebKittens, Recently many non-WebKitGTK+ developers have been kind enough to debug failures that only show up on WebKitGTK+. Since WebKitGTK+ typically tracks bleeding-edge GNOME, compiling can be a daunting task for those not up on the latest GNOME releases. In particular, some of yo

[webkit-dev] Pages from the wiki vanished from google search results

Hi there. Since a couple of days ago (when?), our trac/wiki is not appearing as relevant on google search results anymore. I guess google blacklisted the site because of some sort of spam or a redirect against the rules. Does anyone know if something changed recently? Does someone has a google w

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

> 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 reference by which observable state of this object could be a

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 May 31, 2011, at 10:54 AM, Peter Kasting wrote: > 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

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

>>> Even in a class that is used in a tree, I still think simple member >>> variable accessor methods (that do not return tree neighbors) should be >>> const. >> >> OK. Why? > > Because it indicates to me and the compiler, that the method doesn't have > side effects. A const member function

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] Do we have a style preference about const member functions?

On May 31, 2011, at 10:47 AM, Geoffrey Garen wrote: >> Even in a class that is used in a tree, I still think simple member variable >> accessor methods (that do not return tree neighbors) should be const. > > OK. Why? Because it indicates to me and the compiler, that the method doesn't have s

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

> Even in a class that is used in a tree, I still think simple member variable > accessor methods (that do not return tree neighbors) should be const. OK. Why? Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailm

Re: [webkit-dev] Cherry-Pick Bug Comments

On Thu, May 26, 2011 at 7:54 PM, Eric Seidel wrote: > I get a lot of these: > Revision r86028 cherry-picked into qtwebkit-2.2 with commit 7e1bab1 > > as bug mail.  Probably because I'm CC'd on a zillion bugs (and actually read > my bug mail). >

[webkit-dev] Spellcheck API for WebKit

Greetings WebKit developers, These days, we have talked about adding Spellcheck API in the public-webapps ML: . This API currently consists of two functions (addSpellcheckRange and removeSpellcheckRange) and an attribute (spellche