Martin Robinson | 1 Jun 01:23 2011

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 you are
stuck using Lucid. For those people, I've backported all WebKitGTK+
requirements to Lucid and published them in my PPA. Please
see http://trac.webkit.org/wiki/BuildingGtk for details.

Note: Both Fedora 15 and Ubuntu 11.04 (Natty Narwhal) contain the
required dependencies. If you are not tied to a particular Linux
release I recommend simply upgrading your system rather than using my
PPA.

--Martin
Eric Seidel | 1 Jun 01:30 2011

Re: Pages from the wiki vanished from google search results

Someone could check:


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 <ademar.reis <at> openbossa.org> wrote:
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 webmaster tools account to check?

A few examples:

http://www.google.com/search?hl=en&q=webkit+team+%22Here+is+the+key+for+each%22
http://www.google.com/search?hl=en&q=Qt+Port+of+WebKit+%22List+of+all+QtWebKit+wiki+pages%22

(here only pages mirroring our wiki appear on the search results)

Thanks,
 - Ademar

--
Ademar de Souza Reis Jr. <ademar.reis <at> openbossa.org>
Nokia Institute of Technology
_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Maciej Stachowiak | 1 Jun 01:37 2011
Picon

Re: 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 reference by which observable state of this object could be altered".

Precisely!

I like this explanation too. 

I'm trying to think of a simple way to explain / test whether something falls into the category of logical constness, since it can be ambiguous.

It occurred to me that a simple, though imperfect, test is just, "Is this function called by an owner of a const pointer / reference?" After all, a const member function is meaningless if nobody points to the class through a const pointer  / reference. For classes like DOM and render tree nodes, which have no meaningful const-pointer-owning clients, the answer is always no. For other classes, the answer is yes, but only if someone has found a meaningful use for a const pointer or reference to the class.

So, perhaps the real style question we should answer is when to use const pointers / references, since the answer to when to use const member functions will follow from it.

What are some good examples of existing code that meaningfully uses a const pointer or reference? (Something other than, say, the obligatory const& in a copy constructor.)

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 useful to maintain const-correctness discipline for that class. If we wanted to make the DOM or render tree thoroughly const-correct, the key question would be what client code would access via const pointers or references.

For container classes, it is almost certain that some client will wish to vend or consume const references, even if the very first client doesn't.

There's probably other classes where it's less clear-cut.

Regards,
Maciej

_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Brent Fulgham | 1 Jun 02:55 2011
Picon

Re: Do we have a style preference about const member functions?

Hi,

On Tue, May 31, 2011 at 4:37 PM, Maciej Stachowiak <mjs <at> apple.com> 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
> useful to maintain const-correctness discipline for that class.

I don't agree with this.  I see no harm in maintaining const
correctness on objects, even if they are not currently manipulated
through const references/pointers.  They provide clear,
self-documenting evidence that the object design intends that certain
methods do not visibly alter the object.

I fail to see how abandoning const correctness can do anything but
cause us to start missing bugs that we would otherwise have found via
compiler errors.

-Brent
Maciej Stachowiak | 1 Jun 05:44 2011
Picon

Re: 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 <mjs <at> apple.com> 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
>> useful to maintain const-correctness discipline for that class.
> 
> I don't agree with this.  I see no harm in maintaining const
> correctness on objects, even if they are not currently manipulated
> through const references/pointers.  They provide clear,
> self-documenting evidence that the object design intends that certain
> methods do not visibly alter the object.
> 
> I fail to see how abandoning const correctness can do anything but
> cause us to start missing bugs that we would otherwise have found via
> compiler errors.

It's hard for me to evaluate this in the abstract. In general I like the compiler telling me as much as
possible. But there's both false positive and false negative problems with const-correctness, and a
maintenance burden besides just fixing the compiler errors.

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_previous; }

The correct way to do const-correctness here would require more verbosity:

    const Node* previousSibling() const { return m_previous; }
    Node* previousSibling() { return m_previous; }

And the first variant would be dead code if we don't ever actually use const node pointers.

Given your views on const-correctness discipline, what do you think is the right way to handle this
situation? Note that this pattern comes up for many core DOM methods and many render tree methods.

Regards,
Maciej
Brent Fulgham | 1 Jun 07:00 2011
Picon

Re: 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_previous; }
> 
> The correct way to do const-correctness here would require more verbosity:
> 
>    const Node* previousSibling() const { return m_previous; }
>    Node* previousSibling() { return m_previous; }
> 
> And the first variant would be dead code if we don't ever actually use const node pointers.
> 
> Given your views on const-correctness discipline, what do you think is the right way to handle this
situation? Note that this pattern comes up for many core DOM methods and many render tree methods.

One possible (though ugly) way of allowing the compiler to do some of this work for you is to declare the
m_previous member as a const pointer, and then manipulate it only in specific routines using the
"const_cast" operator to allow it to mutate.  But this is probably a case of the cure being worse than the disease.

If we had logic that iterated over the node siblings in read-only fashion, we would ideally do so through a
const iterator.  In addition to documenting that we don't intend to mutate the object, it would provide
potentially useful information that compilers could use to make aliasing decisions and so forth. 
Perhaps we never iterate over DOM nodes without intending to mutate them; if so, I would agree that there is
no benefit to maintaining the const variation.

However I do not think (as the Node example might imply) that the fact that the compiler cannot identify ALL
categories of const error means that we are better off washing our hands of const correctness.

In fact, due to the viral nature of const-ness changes, leaving them in (and continuing to maintain them) is
a good long term approach since the first time you want to work with a const Node object you will have to
resurrect const variations of methods across the object hierarchy.

-Brent
Maciej Stachowiak | 1 Jun 08:31 2011
Picon

Re: 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" perspective:
>> 
>>   Node* previousSibling() const { return m_previous; }
>> 
>> The correct way to do const-correctness here would require more verbosity:
>> 
>>   const Node* previousSibling() const { return m_previous; }
>>   Node* previousSibling() { return m_previous; }
>> 
>> And the first variant would be dead code if we don't ever actually use const node pointers.
>> 
>> Given your views on const-correctness discipline, what do you think is the right way to handle this
situation? Note that this pattern comes up for many core DOM methods and many render tree methods.
> 
> 
> One possible (though ugly) way of allowing the compiler to do some of this work for you is to declare the
m_previous member as a const pointer, and then manipulate it only in specific routines using the
"const_cast" operator to allow it to mutate.  But this is probably a case of the cure being worse than the disease.

This cure would most definitely be worse than the disease. All JavaScript access to the DOM gets
(effectively) non-const node references, so we'd need to cast away const everywhere.

> 
> If we had logic that iterated over the node siblings in read-only fashion, we would ideally do so through a
const iterator.  In addition to documenting that we don't intend to mutate the object, it would provide
potentially useful information that compilers could use to make aliasing decisions and so forth. 
Perhaps we never iterate over DOM nodes without intending to mutate them; if so, I would agree that there is
no benefit to maintaining the const variation.

It's my understanding that compilers make essentially no use of a method being labeled "const" to enable
optimizations. Given const_cast and mutable, just knowing the signature is const is not a strong enough
guarantee to decide anything at the call site. And if the compilercan see the body of the function, and see
that it actually doesn't mutate the object, it know all it needs to know and are not helped by the const
declaration. Marking methods as const to help the compiler is, as far as I know, simply cargo cult engineering.

> 
> However I do not think (as the Node example might imply) that the fact that the compiler cannot identify ALL
categories of const error means that we are better off washing our hands of const correctness.

Let's set aside the compiler's error checking for the moment. What do you believe is the proper
const-correct way to write previousSibling() and related methods? A priori, I think the correct way is this:

  Node* previousSibling() { return m_previous; }

I could also be convinced that the following is technically more correct, though in a way that is completely
useless for our code base at present:

  const Node* previousSibling() const { return m_previous; }
  Node* previousSibling() { return m_previous; }

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 now violates the intent of const, and so to me at least is clearly a bug:

  Node* previousSibling() const { return m_previous; }

What do you think is the right way to do it? One of these? Something else?

> In fact, due to the viral nature of const-ness changes, leaving them in (and continuing to maintain them)
is a good long term approach since the first time you want to work with a const Node object you will have to
resurrect const variations of methods across the object hierarchy.

Well one big problem right now (just from scanning the core DOM classes) is that we have a lot of clearly
broken use of const. We could (a) leave it as-is, (b) remove the incorrect use of const, or (c) deploy proper
const-correctness. it seems like you are against (b), but I cannot tell if you advocate (a) or (c).

Regards,
Maciej
Karthik | 1 Jun 08:49 2011
Picon

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 platform/graphics/GraphicsTypes.cpp in compositeOperatorNames[] & that's why this issue is present.

When I removed "highlight" from here & also removed "CompositeHighLight  from enum CompositeOperator in GraphicsType.h this issue is resolved (I also had to comment out all other code using CompositeHighLight & CSSValueHighlight ).

However, the following comment was mentioned in GraphicsType.h ("    // Note: These constants exactly match the NSCompositeOperator constants of // AppKit on Mac OS X Tiger. If these ever change, we'll need to change the // Mac OS X Tiger platform code to map one to the other. "). So I am little unclear what is the purpose of this CompositeHighLight.

Can someone please help me out here.

Thanks & Regards,
Karthik

_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Darin Adler | 1 Jun 18:21 2011
Picon

Re: Issue Analysis:48290 [HTML Canvas globalCompositeOperation]

On May 31, 2011, at 11:49 PM, Karthik wrote:

> However, the following comment was mentioned in GraphicsType.h ("    // Note: These constants exactly
match the NSCompositeOperator constants of // AppKit on Mac OS X Tiger. If these ever change, we'll need to
change the // Mac OS X Tiger platform code to map one to the other. "). So I am little unclear what is the
purpose of this CompositeHighLight.

We can remove that comment. It’s obsolete.

I believe the “highlight” compositing mode used to be supported in canvas by WebKit on Mac, but
hasn’t been for some time. There’s probably no harm in removing it now.

The fact that the string is “not valid” in the specification isn’t what makes it OK to remove. Please
remember that the canvas implementation in WebKit was the first and predates the specification by at
least a year. But it’s almost certainly OK to remove this compositing mode because it hasn’t been
implemented for quite a while.

There’s still a slim chance that there is some content out there relying on “highlight” being a
synonym for “source-over”, but it’s not likely.

One side comment: I think the mapping from strings to the various graphics enums really belongs in the
canvas code, not in the platform directory.

    -- Darin
Mustafizur Rahaman | 1 Jun 19:14 2011
Picon

Re: Issue Analysis:48290 [HTML Canvas globalCompositeOperation]

Hi Darin,

Thanks for your detailed explanation. Initially we decided to remove the string as well the enum to fix this issue. But Karthik's patch (we have already submitted the patch in https://bugs.webkit.org/show_bug.cgi?id=48290 ) caused a Chromium build issue & then we found that this enum is used in lot of other places. So, we were a little apprehensive about the side effect of this fix.

Therefore, we submitted another patch where we are returning from the canvas code itself if the compositing mode is "highlight". We are still waiting for the review comments.

Similar issue (https://bugs.webkit.org/show_bug.cgi?id=48289 ) we have also seen for "darker"/CompositePlusDarker (not a valid compositing mode any more). Can we also remove this as well?

Thanks,
Rahaman

On Wed, Jun 1, 2011 at 9:51 PM, Darin Adler <darin <at> apple.com> wrote:
On May 31, 2011, at 11:49 PM, Karthik wrote:

> However, the following comment was mentioned in GraphicsType.h ("    // Note: These constants exactly match the NSCompositeOperator constants of // AppKit on Mac OS X Tiger. If these ever change, we'll need to change the // Mac OS X Tiger platform code to map one to the other. "). So I am little unclear what is the purpose of this CompositeHighLight.

We can remove that comment. It’s obsolete.

I believe the “highlight” compositing mode used to be supported in canvas by WebKit on Mac, but hasn’t been for some time. There’s probably no harm in removing it now.

The fact that the string is “not valid” in the specification isn’t what makes it OK to remove. Please remember that the canvas implementation in WebKit was the first and predates the specification by at least a year. But it’s almost certainly OK to remove this compositing mode because it hasn’t been implemented for quite a while.

There’s still a slim chance that there is some content out there relying on “highlight” being a synonym for “source-over”, but it’s not likely.

One side comment: I think the mapping from strings to the various graphics enums really belongs in the canvas code, not in the platform directory.

   -- Darin

_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Gmane