[webkit-dev] [WebKit2] Shared Secondary Thread Model for GTK+ port
Hi, While trying to understand different process models in WebKit2 in GTK+ port, I found Shared Secondary Thread model is not implemented. I am interested to know if anybody is working on it or any patch is available for initial checking. Thanks Regards, Rosen Dash +91 9716527555 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CamanJS Benchmark: what's wrong with WebKit
Please file a bug at bugs.webkit.org for this. Simon On May 29, 2011, at 10:40 PM, haithem rahmani wrote: Hi all, I've found this blog: http://blog.meltingice.net/programming/camanjs-benchmark-firefox-4-beta-kicking-chromes-ass/ I tested and found the following results on a Core2 Duo 2.66 GHZ /Fedora 15 all webkit ports are really far from the firefox 4 :( firefox4 Arora0.11.0(webkit 533.3) chrome (11.0.696.71)midori(webkitgtk-1.4.0) brightness320ms12570ms3239ms 7613ms clipi 352ms23830ms2723ms 7048ms colorize 313ms34424ms 3461ms 6474ms contrast937ms29330ms 4758ms 7593ms gamma 376ms49212ms 3920ms 6283ms greyscale 277ms28935ms 3796ms 6150ms hue 853ms33353ms3675ms 6660ms invert228ms37749ms2684ms 6118ms noise247ms24039ms3325ms 6195ms saturation 488ms17916ms 2943ms 6845ms sepia244ms31918ms 3420ms 6239ms regards. Haithem. -- If you ask a question - you will be a fool for 5 minutes, otherwise ignorant for rest of your life ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Please kill old pywebsocket process if you see WebSocket test failures
Hi webkit-dev, If the following two tests are failing, it's probably because an old pywebsocket process is still alive and preventing the new one from starting: http/tests/websocket/tests/client-close.html http/tests/websocket/tests/server-close.html You can observe the following traceback in the layout test output: Traceback (most recent call last): File Tools/Scripts/new-run-webkit-websocketserver, line 108, in module main() File Tools/Scripts/new-run-webkit-websocketserver, line 103, in main pywebsocket.start() File /Volumes/Big/WebKit-BuildSlave/leopard-intel-release-tests/build/Tools/Scripts/webkitpy/layout_tests/port/websocket_server.py, line 220, in start (self._server_name, self._port)) webkitpy.layout_tests.port.websocket_server.PyWebSocketNotStarted: Failed to start PyWebSocket server on port 8880. If this happens, please kill the old pywebsocket process, or reboot the machine. *Dear WebKit buildbot administrators:* A couple of buildbot slaves are affected by this issue (as far as I know). Specifically: - apple-macpro-4 ( http://build.webkit.org/builders/Leopard%20Intel%20Release%20%28Tests%29/builds/32745 ) - apple-xserve-7 ( http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20%28WebKit2%20Tests%29/builds/12121 ) Could you kill old pywebsocket processes in these bots? After killing them, the above two tests should start to pass. *Dear webkitpy hackers:* run-webkit-websocketserver probably should check if there's any existing WebSocket server running, and kill it before starting the new one. However, as I don't know very much about how run-webkit-websocketserver works, I don't know if this is feasible or not. Do you think this is a good idea? Is it easily implementable? Sorry for all the mess, and thank you for your cooperation. Regards, Yuta ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CamanJS Benchmark: what's wrong with WebKit
done! https://bugs.webkit.org/show_bug.cgi?id=61722 https://bugs.webkit.org/show_bug.cgi?id=61722 On Mon, May 30, 2011 at 7:17 AM, Simon Fraser simon.fra...@apple.comwrote: Please file a bug at bugs.webkit.org for this. Simon On May 29, 2011, at 10:40 PM, haithem rahmani wrote: Hi all, I've found this blog: http://blog.meltingice.net/programming/camanjs-benchmark-firefox-4-beta-kicking-chromes-ass/ I tested and found the following results on a Core2 Duo 2.66 GHZ /Fedora 15 all webkit ports are really far from the firefox 4 :( firefox4 Arora0.11.0(webkit 533.3) chrome (11.0.696.71)midori(webkitgtk-1.4.0) brightness320ms12570ms3239ms 7613ms clipi 352ms23830ms 2723ms 7048ms colorize 313ms34424ms 3461ms 6474ms contrast937ms29330ms 4758ms 7593ms gamma 376ms49212ms 3920ms 6283ms greyscale 277ms28935ms 3796ms 6150ms hue 853ms33353ms3675ms 6660ms invert228ms37749ms 2684ms 6118ms noise247ms24039ms3325ms 6195ms saturation 488ms17916ms 2943ms 6845ms sepia244ms31918ms 3420ms 6239ms regards. Haithem. -- * If you ask a question - you will be a fool for 5 minutes, otherwise ignorant for rest of your life * ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- * If you ask a question - you will be a fool for 5 minutes, otherwise ignorant for rest of your life * ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Cherry-Pick Bug Comments
On Sun, May 29, 2011 at 8:38 PM, Ojan Vafai o...@chromium.org wrote: I think we should be able to make everyone happy if we handle these the same way we handle the EWS and style bots. The data lives on another server (appengine in this case) and is brought into the bugzilla page via an iframe. We could have an iframe for the Qt release that is empty by default, but shows a link to the release when that patch has been integrated into a branch. Hi Ojan. I'm not sure I understand what you mean... Could you give me an example? Thanks, - Ademar On Fri, May 27, 2011 at 2:29 PM, James Robinson jam...@google.com wrote: I find these cherry-pick bug comments annoying and hope that you will stop generating them. There are many ports that make releases based off of WebKit trunk, and all of them have some notion of release branches that contain cherry-picked revisions, reverts, etc. As a developer it's nearly always irrelevant to me whether a given patch is cherry-picked into a given Qt release or not, just as it would be to know if that revision was cherry-picked into a given Gtk, EFL, Safari, or Chromium release branch. When I do need to know the status of a specific branch, I look in the port-specific location of the branch to see what happened. For example, to see what's in a given chromium release I look in the appropriate subdirectory of http://trac.webkit.org/browser/branches/chromium. For the Safari 534 branch, http://trac.webkit.org/browser/branches/safari-534-branch etc. I would recommend that the people who work on QtWebKit figure out a way to track revisions in their release branches in a way that does not involve spamming non-Qt bugs on bugs.webkit.org or developers who aren't working directly on Qt. - James On Fri, May 27, 2011 at 10:27 AM, Antonio Gomes toniki...@gmail.com wrote: An important question: besides the notification e-mails, does the rest of our release process bothers someone? Not me. It works fine and is very transparent. -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Ademar de Souza Reis Jr. ademar.r...@openbossa.org Nokia Institute of Technology ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Cherry-Pick Bug Comments
On Fri, May 27, 2011 at 6:29 PM, James Robinson jam...@google.com wrote: I find these cherry-pick bug comments annoying and hope that you will stop generating them. There are many ports that make releases based off of WebKit trunk, and all of them have some notion of release branches that contain cherry-picked revisions, reverts, etc. As a developer it's nearly always irrelevant to me whether a given patch is cherry-picked into a given Qt release or not, just as it would be to know if that revision was cherry-picked into a given Gtk, EFL, Safari, or Chromium release branch. When I do need to know the status of a specific branch, I look in the port-specific location of the branch to see what happened. For example, to see what's in a given chromium release I look in the appropriate subdirectory of http://trac.webkit.org/browser/branches/chromium. For the Safari 534 branch, http://trac.webkit.org/browser/branches/safari-534-branch etc. I would recommend that the people who work on QtWebKit figure out a way to track revisions in their release branches in a way that does not involve spamming non-Qt bugs on bugs.webkit.org or developers who aren't working directly on Qt. Hi James. Does the fact that the comment appears in the bug annoys you, or the fact that you receive an e-mail notification? (because one of the potential solutions is to add the comment without triggering an e-mail) Thanks, - Ademar On Fri, May 27, 2011 at 10:27 AM, Antonio Gomes toniki...@gmail.com wrote: An important question: besides the notification e-mails, does the rest of our release process bothers someone? Not me. It works fine and is very transparent. -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Ademar de Souza Reis Jr. ademar.r...@openbossa.org Nokia Institute of Technology ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding CSS Regions and Exclusions to WebKit
On 5/26/11 3:08 PM, David Hyatt hy...@apple.com wrote: On May 26, 2011, at 4:31 PM, Eric Seidel wrote: I appreciate that you've followed the master-bug idiom which is so common in bugs.webkit.org http://bugs.webkit.org/ these days! I also would *strongly* encourage you to post your changes in as small of patches as possible. Integrating features which have been developed outside webkit.org http://webkit.org/ is always difficult, but doing things in small (or even tiny!) patches will make your life easiest in the long run. I'm happy to help review your (small!) changes if CC'd. I've encouraged them to begin with the CSS property back end, i.e., getting the new properties and values in and parsed. I think it will be a good introduction to our process to start there, and it will also let them get familiar with writing regression tests. I think those patches are more easily reviewed by many people as well, unlike the layout and rendering changes, which are quite advanced. Following this advice, we’re preparing some initial patches that only contain the parsing code. I have been looking for pure parsing tests to use as examples for the tests we will need to submit with these patches, but I haven’t yet found anything to go on. I’m guessing that I’m not looking in the right place, or (for those who have followed this patch trajectory before) initial parsing tests get replaced with functional tests over time. Does anyone have an example of good parsing validation they can point me to? Thanks, Alan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Font Name
I can add to this that If someone wants to work on text rendering and doesn't
want to deal with html or CSS parsing, he can find an index for the font family
under:
Font-m_fontDescription-m_familyList-m_family-m_Data.
I know for example that index for monospace family is 67 or for times new roman
is 84 but I still don't know if there is a table some where about all indexes
for font families.
Soheil Servati Beiragh
PhD Candidate, ECE Department,
Research Center for Integrated Microsystems,
University of Windsor.
Room 268 Essex Hall
401 Sunset Avenue
Windsor, Ontario
Canada, N9B 3P4
Phone: 519-253-3000 Ext 3396
Email: serv...@uwindsor.ca
From: Eric Seidel e...@webkit.org
To: Mustafizur Rahaman mustaf.h...@gmail.com
Cc: Soheil Servati sserv...@yahoo.com; WebKit Development
webkit-dev@lists.webkit.org
Sent: Sunday, May 29, 2011 12:59 PM
Subject: Re: [webkit-dev] Font Name
There are a couple steps missing, but this hits most of the important points.
I think one could turn such into a blog post with diagrams if so desired.
-eric
On Sat, May 21, 2011 at 5:55 PM, Mustafizur Rahaman mustaf.h...@gmail.com
wrote:
Hi,
When you are drawing some text, you create a RenderText(RenderObject) which
has all the rendering info the m_style of RenderText has the style info
required to render the text.
Let's consider the following style data I have in my html page
style type=text/css
body.rahaman{
font:30px courier;
}
/style
body class=rahaman Rahaman /body
Once the HTMLTreeBuilder parses the token, it creates HTMLStyleElement
CSSStyleSheet then asks the CSSParser to parse the StyleSheet. From there it
comes to CSSParser::parseValue()=CSSParser::parseFont() as the I have only
used font property
We create a FontValue (which contain all the attribute a font property can
have like style, size, variant, family etc= in this font_family, you can
actually see the font name you have used ). In CSSParser::parseFont, we
populate the FontValue structure (you can find the font family name in
font-family), calls CSSParser::addProperty() where we create a CSSProperty
with the FontValue/CSSValue being passed this property is being stored in
CSSParser::m_parsedProperties.
Then we call CSSParser::createStyleRule where we used the m_parsedProperties
mentioned before to create a CSSMutableStyleDeclaration set this declaration
for the CSSRule.
We then create CSSStyleSelector and call CSSStyleSelector::styleForElement for
the root element. Here somehow (I don't have much details what happens in
berween but figured out that we retrieve the same CSSMutableStyleDeclaration
mentioned above) call CSSStyleSelector::applyProperty(). Here each
StyleSelector has its RenderStyle (m_style), where from we retrieve the
FontDescription add the properties accordingly. On the other hand, each
RenderObject (the corresponding node in the RenderTree for a node in DOM tree)
has RenderStyle, which gets the value we retrieved above.
Finally we call GraphicsContext::drawText() passing the Font which we have
retrieved from the RenderStyle we dsicussed above.
I am not sure if this is what you were looking for, I just shared whatever I
knew of the related area. Please let me know if you need anything else.
Thanks,
Rahaman
On Fri, May 20, 2011 at 12:22 AM, Soheil Servati Beiragh sserv...@yahoo.com
wrote:
Hi
I want to know after webkit parses the html file where does it save the font
that is used for text? It definitely won't save a name for the font but there
should be some kind of index or sth to tell the rendering engine which font
is being used.
Thanks in advance
Soheil Servati Beiragh
PhD Candidate, ECE Department,
Research Center for Integrated Microsystems,
University of Windsor.
Room 268 Essex Hall
401 Sunset Avenue
Windsor, Ontario
Canada, N9B 3P4
Phone: 519-253-3000 Ext 3396
Email: serv...@uwindsor.ca
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Glyph data in Rendering Text
I didn't found #webkit in the list when I used the IRC chat client software. Soheil Servati Beiragh PhD Candidate, ECE Department, Research Center for Integrated Microsystems, University of Windsor. Room 268 Essex Hall 401 Sunset Avenue Windsor, Ontario Canada, N9B 3P4 Phone: 519-253-3000 Ext 3396 Email: serv...@uwindsor.ca From: Eric Seidel e...@webkit.org To: Soheil Servati Beiragh sserv...@yahoo.com Sent: Sunday, May 29, 2011 4:50 PM Subject: Re: [webkit-dev] Glyph data in Rendering Text #webkit-efl is not likely as useful as #webkit. EFL is just a port, #webkit is where the core devs hang out. On Wed, May 18, 2011 at 3:24 PM, Soheil Servati Beiragh sserv...@yahoo.com wrote: I couldn't manage to find you on IRC yet. I joined the channel #webkit-efl but for now no luck. Any way... I'm working on a new text layout scheme for webkit That sounds like a bad idea... What do you mean by a new text layout scheme? Is it spec'd anywhere? Does any other browser do the scheme in question? How does it interact with CSS layout? and I needed to find out: 1. Does webkit renders bitmap glyphs before it starts to do layout or it just uses the data from font file for metrics? WebKit does not render glyphs. The platform's font system does. Source/WebCore/platform/graphics (and /text) have abstractions for taling to the various platform font systems. 2. If it does, where does it save the bitmap glyphs and if not where it saves the data from font file? Again, this is all handled by the underlying platform libraries. WebCore keeps a glyph cache. Where it caches glyph identifiers (pointers on some platforms) as well as some measurement information per-character. But it just hands those identifiers off to the platform again to do the drawing. 3. I need to find out where it gives the layout engine the size of the block for text and the position of the block on screen? This sort of information is calculated during layout() and stored on the RenderObjects. RenderBoxModelObject is the superclass for all RenderObjects which layout according to the CSS box model (which you can search for on google and read more about). Search for my name on YouTube to find a video describing some of this. Thanks for your attention Again, inventing a new layout scheme is probably a bad idea. Designing one in a research paper is fine, but you probably won't want to implement it... :) SVG Text has some of its own line layout. You'll need to learn more about the line box tree. (InlineBox and subclasses.) MathML also does some of its own layout modifications on top of CSS line layout. Best of luck. Soheil Servati Beiragh PhD Candidate, ECE Department, Research Center for Integrated Microsystems, University of Windsor. Room 268 Essex Hall 401 Sunset Avenue Windsor, Ontario Canada, N9B 3P4 Phone: 519-253-3000 Ext 3396 Email: serv...@uwindsor.ca From: Eric Seidel e...@webkit.org To: Soheil Servati Beiragh sserv...@yahoo.com Sent: Tuesday, May 17, 2011 4:35 PM Subject: Re: [webkit-dev] Glyph data in Rendering Text Did you find your answer? I'm on #webkit as 'eseidel' On Mon, May 16, 2011 at 12:40 PM, Eric Seidel e...@webkit.org wrote: http://www.webkit.org/contact.html On May 16, 2011 12:25 PM, Soheil Servati Beiragh sserv...@yahoo.com wrote: what do you mean by #webkit? Soheil Servati Beiragh PhD Candidate, ECE Department, Research Center for Integrated Microsystems, University of Windsor. Room 268 Essex Hall 401 Sunset Avenue Windsor, Ontario Canada, N9B 3P4 Phone: 519-253-3000 Ext 3396 Email: serv...@uwindsor.ca From: Eric Seidel e...@webkit.org To: Soheil Servati Beiragh sserv...@yahoo.com Sent: Monday, May 16, 2011 2:11 PM Subject: Re: [webkit-dev] Glyph data in Rendering Text Best to discuss this on #webkit. On Mon, May 16, 2011 at 10:58 AM, Soheil Servati Beiragh sserv...@yahoo.com wrote: In the while loop on line 1944 of RenderBlockLineLayout.cpp the script should use the width of characters from glyph metrics to determine where to put the line break. I want to know where it looks for that data. I did searched and grep the webcore/platform/graphics before but nothing useful in glyph header files so far! Soheil Servati Beiragh PhD Candidate, ECE Department, Research Center for Integrated Microsystems, University of Windsor. Room 268 Essex Hall 401 Sunset Avenue Windsor, Ontario Canada, N9B 3P4 Phone: 519-253-3000 Ext 3396 Email: serv...@uwindsor.ca From: Eric Seidel e...@webkit.org To: Soheil Servati Beiragh sserv...@yahoo.com Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Sent: Monday, May 16, 2011 1:50 PM Subject: Re: [webkit-dev] Glyph data in Rendering Text Look under Sources/WebCore/platform/graphics. Or just grep the source directory for glyph. :) -eric On Mon, May
Re: [webkit-dev] Cherry-Pick Bug Comments
On Mon, May 30, 2011 at 6:07 AM, Ademar Reis ademar.r...@openbossa.orgwrote: On Sun, May 29, 2011 at 8:38 PM, Ojan Vafai o...@chromium.org wrote: I think we should be able to make everyone happy if we handle these the same way we handle the EWS and style bots. The data lives on another server (appengine in this case) and is brought into the bugzilla page via an iframe. We could have an iframe for the Qt release that is empty by default, but shows a link to the release when that patch has been integrated into a branch. Hi Ojan. I'm not sure I understand what you mean... Could you give me an example? Take a look at https://bugs.webkit.org/show_bug.cgi?id=61727. Under Review Patch https://bugs.webkit.org/attachment.cgi?id=95342action=review | Details https://bugs.webkit.org/attachment.cgi?id=95342action=edit | Formatted Diff https://bugs.webkit.org/attachment.cgi?id=95342action=prettypatch | Diff https://bugs.webkit.org/attachment.cgi?id=95342action=diff, there is an iframe that contains the results from the various queues that patch has been run through. We could similarly have an iframe dedicated to the qt release process. Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do we have a style preference about const member functions?
OK, how about this style guideline: Const member functions: Do use const member functions in classes that are simple data holders, to help distinguish between references that can modify the data and references that can't. Do not use const member functions in complex classes that do a lot more than hold one piece of data, since the distinction is weak. Do not use const member functions for DOM or render tree nodes. Geoff On May 29, 2011, at 1:20 PM, Darin Adler wrote: On May 28, 2011, at 5:15 PM, Geoffrey Garen wrote: This came up in https://bugs.webkit.org/show_bug.cgi?id=59604. My personal preference is against const member functions because they force many error-prone code changes: introducing a const forces the transitive closure of all potential callees to change their signatures recursively, and if you get this wrong in the case of a virtual function, you introduce a very subtle set of bugs. I think we do currently overuse const. There are many objects that are not really data holders, and it does not seem all that helpful to distinguish a const member function on such an object. I don't see much upside to const member functions because they're just an unenforced convention: sub-object and mutable data members are still non-const inside a so-called const function, and you can always const_cast away so-called const-ness, as WebKit currently does in 483 places. I don’t fully agree. Although const is not an airtight mechanism, it can be helpful to make clear which functions are intended to have side effects and which are not. It’s helped me notice programming mistakes in the past. I don’t think the presence of mutable invalidates the helpfulness of const. I also don’t think the total number of calls to const_cast in WebKit is a good metric of how well const is working as a design pattern. Many of those calls are required due to working with libraries outside of WebKit such as CoreFoundation. I think we should stop using const member functions on classes where the distinction is weak and it’s not paying off. The classes that immediately come to mind are the DOM elements and render tree nodes. Having a const pointer to one node in a tree is not all that meaningful since the const-ness is immediately lost if you move to a neighbor. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do we have a style preference about const member functions?
On Mon, May 30, 2011 at 4:02 PM, Geoffrey Garen gga...@apple.com wrote: Do not use const member functions in *complex classes that do a lot more than hold one piece of data* I'm not sure if the complexity of a class or holding piece of data are useful criteria. Looking at DOM or render tree, it seems that we don't want to use const when *an object constitutes (i.e. object's data members are essential in creating) a larger data structure such as a tree or a list*. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do we have a style preference about const member functions?
Updated: Const member functions: Do use const member functions in classes that are independent data holders, to help distinguish between references that can modify the data and references that can't. Do not use const member functions in classes that participate in object graphs, since the distinction is weak. Do not use const member functions for DOM or render tree nodes. Geoff On May 30, 2011, at 4:08 PM, Ryosuke Niwa wrote: On Mon, May 30, 2011 at 4:02 PM, Geoffrey Garen gga...@apple.com wrote: Do not use const member functions in complex classes that do a lot more than hold one piece of data I'm not sure if the complexity of a class or holding piece of data are useful criteria. Looking at DOM or render tree, it seems that we don't want to use const when an object constitutes (i.e. object's data members are essential in creating) a larger data structure such as a tree or a list. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do we have a style preference about const member functions?
On May 30, 2011, at 4:19 PM, Geoffrey Garen wrote: Updated: Const member functions: Do use const member functions in classes that are independent data holders, to help distinguish between references that can modify the data and references that can't. Do not use const member functions in classes that participate in object graphs, since the distinction is weak. Do not use const member functions for DOM or render tree nodes. 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. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
