Re: [webkit-dev] Tagging bug names with a platform name: limit to platform-specific patches
Darin Adler wrote: Hi folks. We’ve never formalized this, but I believe that patches tagged with a particular platform name such as [Qt] Add new API for fluffy bunnies should be limited to one particular platform’s code. If the patch changes more than a trivial bit of platform-independent code, even if the change is only for the benefit of a signle platform, I suggest we not use the platform name prefix. Agreed. Note also that we have keywords for both Qt and Gtk, so if a patch deals largely with platform-independent code, but has consequences for either of these ports, for example new API requirements or DRT hooks, please add the keyword to it pops up in filters. tor arne ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Tagging bug names with a platform name: limit to platform-specific patches
On Thu, Jan 21, 2010 at 10:58 AM, Maciej Stachowiak m...@apple.com wrote: On Jan 20, 2010, at 8:18 AM, Darin Adler wrote: Hi folks. We’ve never formalized this, but I believe that patches tagged with a particular platform name such as [Qt] Add new API for fluffy bunnies should be limited to one particular platform’s code. If the patch changes more than a trivial bit of platform-independent code, even if the change is only for the benefit of a signle platform, I suggest we not use the platform name prefix. Makes sense to me. I would also like to suggest that people should *not* use the bracket convention for things besides platform, like [dom] or [style-queue]. Some people (e.g. me) use queries to split bracket-prefix patches into a separate list, and it's better not to hide general-purpose patches. Sorry for using those, tried to be a good citizen :) Should be tags like dom, v8 omitted completely or is there some other way to communicate the system? yours, anton. ___ 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] Font layout features
Any pointers at all would be greatly appreciated! -Original Message- From: Jason Rukman Sent: Wednesday, January 20, 2010 9:49 AM To: webkit-dev@lists.webkit.org Subject: Font layout features As part of our port to windows CE we are using a Cairo configuration combined with freetype. This is fairly similar to the Windows port but we are not using the native Windows GDI/cairo layer for fonts (instead we are using cairo-ft). However, unlike the GTK port, we did not port Pango, and so are using Cairo font layout. Can someone comment on what limitation we may have with Asian fonts/glyphs or other issues with this configuration? We have ported the latest versions of freetype, fontconfig and cairo to CE. Thanks, Jason. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Font layout features
On Wed, Jan 20, 2010 at 9:49 AM, Jason Rukman jas...@bsquare.com wrote: As part of our port to windows CE we are using a Cairo configuration combined with freetype. This is fairly similar to the Windows port but we are not using the native Windows GDI/cairo layer for fonts (instead we are using cairo-ft). However, unlike the GTK port, we did not port Pango, and so are using Cairo font layout. Can someone comment on what limitation we may have with Asian fonts/glyphs or other issues with this configuration? We have ported the latest versions of freetype, fontconfig and cairo to CE. It is difficult to answer your question, because it depends on what you are doing. Where is the code? cairo_show_text() is the API to take pause at: http://www.cairographics.org/manual/cairo-text.html#cairo-show-text Note: The cairo_show_text() function call is part of what the cairo designers call the toy text API. It is convenient for short demos and simple programs, but it is not expected to be adequate for serious text-using applications. See cairo_show_glyphs() for the real text display API in cairo. But I guess you must be doing some sort of interfacing with Freetype because WebKit wants glyph extents, etc, which makes me guess you're using a lower layer. In general, you can gain or lose confidence in the quality of your port by running the layout tests. If there are any text rendering problems that you see that aren't covered by the layout tests, we should just create more tests. (I have yet another bug in my queue to add some more tricky Arabic ones that came up in doing font stuff for Chrome...) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Anonymous Rendering Objects in Web Inspector
In my MathML code I often wrap the direct rendering objects for a particular element in an anonymous rendering object. When I inspect these elements I get the particular rendering object for the element but between that element and the parent's rendering object there are these anonymous objects used for layout control. Is there some way to see these objects when you inspect the element? Is there another tool I can use to inspect the render object tree? -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Font layout features
Thanks for the reply Evan!
We are using the same code as the windows Cairo port for glyph rendering so
FontCairo which only uses cairo_show_glyphs.
The only difference is that our port of Cairo is using cairo-ft instead of
cairo-win32-font and we've brought the freetype font support over from the gtk
port.
I guess my main question is; What does pango do for the gtk port? Do I need
to worry that we are not using it and just using freetype?
We have the layout tests running but at this point we aren't running the pixel
tests; is this necessary for the text rendering tests to show up issues or will
we be hitting the necessary tests without them?
I've been working to get our tree in a state we can open it up; I'm sorry I'm
not quite there yet.
Here's one stack trace that hits cairo_show_glyphs:
WebKit.dll!cairo_show_glyphs(_cairo* cr = 0x011836e0, cairo_glyph_t*
glyphs = 0x0011baf0, int num_glyphs = 18) Line: 3162, Byte Offsets: 0x10 C
WebKit.dll!WebCore::Font::drawGlyphs(WebCore::GraphicsContext* context
= 0x0012f700, WebCore::SimpleFontData* font = 0x00c58380, WebCore::GlyphBuffer
glyphBuffer = {...}, int from = 0, int numGlyphs = 18, WebCore::FloatPoint
point = {...}) Line: 152, Byte Offsets: 0x7c0C++
WebKit.dll!WebCore::Font::drawGlyphBuffer(WebCore::GraphicsContext*
context = 0x0012f700, WebCore::GlyphBuffer glyphBuffer = {...},
WebCore::TextRun __formal = {...}, WebCore::FloatPoint point = {...}) Line:
316, Byte Offsets: 0x1ac C++
WebKit.dll!WebCore::Font::drawSimpleText(WebCore::GraphicsContext*
context = 0x0012f700, WebCore::TextRun run = {...}, WebCore::FloatPoint point
= {...}, int from = 0, int to = 18) Line: 289, Byte Offsets: 0x26c C++
WebKit.dll!WebCore::Font::drawText(WebCore::GraphicsContext* context =
0x0012f700, WebCore::TextRun run = {...}, WebCore::FloatPoint point = {...},
int from = 0, int to = 18) Line: 179, Byte Offsets: 0x118 C++
WebKit.dll!WebCore::GraphicsContext::drawText(WebCore::Font font =
{...}, WebCore::TextRun run = {...}, WebCore::IntPoint point = {...}, int
from = 0, int to = 18) Line: 338, Byte Offsets: 0x5cC++
WebKit.dll!WebCore::paintTextWithShadows(WebCore::GraphicsContext*
context = 0x0012f700, WebCore::Font font = {...}, WebCore::TextRun textRun =
{...}, int startOffset = 0, int endOffset = 18, int truncationPoint = 18,
WebCore::IntPoint textOrigin = {...}, int x = 8, int y = 19, int w = 193, int
h = 28, WebCore::ShadowData* shadow = 0x, bool stroked = false) Line:
308, Byte Offsets: 0x258 C++
WebKit.dll!WebCore::InlineTextBox::paint(WebCore::RenderObject::PaintInfo
paintInfo = {...}, int tx = 8, int ty = 19) Line: 499, Byte Offsets: 0x1084 C++
WebKit.dll!WebCore::InlineFlowBox::paint(WebCore::RenderObject::PaintInfo
paintInfo = {...}, int tx = 8, int ty = 19) Line: 677, Byte Offsets: 0x42c C++
WebKit.dll!WebCore::InlineFlowBox::paint(WebCore::RenderObject::PaintInfo
paintInfo = {...}, int tx = 8, int ty = 19) Line: 677, Byte Offsets: 0x42c C++
WebKit.dll!WebCore::RootInlineBox::paint(WebCore::RenderObject::PaintInfo
paintInfo = {...}, int tx = 8, int ty = 19) Line: 167, Byte Offsets: 0x20C++
(tons more removed)
Thanks again,
Jason.
-Original Message-
From: ev...@google.com [mailto:ev...@google.com] On Behalf Of Evan Martin
Sent: Thursday, January 21, 2010 9:17 AM
To: Jason Rukman
Cc: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Font layout features
On Wed, Jan 20, 2010 at 9:49 AM, Jason Rukman jas...@bsquare.com wrote:
As part of our port to windows CE we are using a Cairo configuration combined
with freetype. This is fairly similar to the Windows port but we are not
using the native Windows GDI/cairo layer for fonts (instead we are using
cairo-ft). However, unlike the GTK port, we did not port Pango, and so are
using Cairo font layout. Can someone comment on what limitation we may have
with Asian fonts/glyphs or other issues with this configuration? We have
ported the latest versions of freetype, fontconfig and cairo to CE.
It is difficult to answer your question, because it depends on what
you are doing. Where is the code?
cairo_show_text() is the API to take pause at:
http://www.cairographics.org/manual/cairo-text.html#cairo-show-text
Note: The cairo_show_text() function call is part of what the cairo
designers call the toy text API. It is convenient for short demos
and simple programs, but it is not expected to be adequate for serious
text-using applications. See cairo_show_glyphs() for the real text
display API in cairo.
But I guess you must be doing some sort of interfacing with Freetype
because WebKit wants glyph extents, etc, which makes me guess you're
using a lower layer.
In general, you can gain or lose confidence in the quality of your
port by running the layout tests. If there are any text rendering
problems that you see that aren't covered
Re: [webkit-dev] Font layout features
On Thu, Jan 21, 2010 at 10:23 AM, Jason Rukman jas...@bsquare.com wrote: I guess my main question is; What does pango do for the gtk port? Do I need to worry that we are not using it and just using freetype? Complex text. Without Pango or Harfbuzz or ICU you won't properly display Arabic, Hebrew, Indic scripts, and strange combinations of more ordinary letters involving combining characters m plus acute. CJK ought to work though. We have the layout tests running but at this point we aren't running the pixel tests; is this necessary for the text rendering tests to show up issues or will we be hitting the necessary tests without them? Some layout tests may catch some of these issues, but you probably need pixels to verify the actual scripts come out ok. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Font layout features
On Thu, Jan 21, 2010 at 10:41 AM, Evan Martin e...@chromium.org wrote: On Thu, Jan 21, 2010 at 10:23 AM, Jason Rukman jas...@bsquare.com wrote: I guess my main question is; What does pango do for the gtk port? Do I need to worry that we are not using it and just using freetype? Complex text. Without Pango or Harfbuzz or ICU you won't properly display Arabic, Hebrew, Indic scripts, and strange combinations of more ordinary letters involving combining characters m plus acute. Sorry, left out a key phrase above: 'and strange combinations of more ordinary letters involving combining characters *SUCH AS* m plus acute.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Font layout features
I'm also using icu... does this mean I should be ok? -Original Message- From: ev...@google.com [mailto:ev...@google.com] On Behalf Of Evan Martin Sent: Thursday, January 21, 2010 10:41 AM To: Jason Rukman Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Font layout features On Thu, Jan 21, 2010 at 10:23 AM, Jason Rukman jas...@bsquare.com wrote: I guess my main question is; What does pango do for the gtk port? Do I need to worry that we are not using it and just using freetype? Complex text. Without Pango or Harfbuzz or ICU you won't properly display Arabic, Hebrew, Indic scripts, and strange combinations of more ordinary letters involving combining characters m plus acute. CJK ought to work though. We have the layout tests running but at this point we aren't running the pixel tests; is this necessary for the text rendering tests to show up issues or will we be hitting the necessary tests without them? Some layout tests may catch some of these issues, but you probably need pixels to verify the actual scripts come out ok. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Font layout features
Just to clarify. Using freetype with ICU alone isn't sufficient without pango or harfbuzz for Arabic et al? -Original Message- From: ev...@google.com [mailto:ev...@google.com] On Behalf Of Evan Martin Sent: Thursday, January 21, 2010 10:45 AM To: Jason Rukman Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Font layout features On Thu, Jan 21, 2010 at 10:42 AM, Jason Rukman jas...@bsquare.com wrote: I'm also using icu... does this mean I should be ok? I meant ICU for shaping. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Font layout features
On Thu, Jan 21, 2010 at 10:59 AM, Jason Rukman jas...@bsquare.com wrote: Just to clarify. Using freetype with ICU alone isn't sufficient without pango or harfbuzz for Arabic et al? ICU is a big library. It depends on where and how you're using it. Why not just try some Arabic text and see? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Anonymous Rendering Objects in Web Inspector
On Thu, Jan 21, 2010 at 10:43 AM, Dan Bernstein m...@apple.com wrote: On Jan 21, 2010, at 9:44 AM, Alex Milowski wrote: In my MathML code I often wrap the direct rendering objects for a particular element in an anonymous rendering object. When I inspect these elements I get the particular rendering object for the element but between that element and the parent's rendering object there are these anonymous objects used for layout control. Is there some way to see these objects when you inspect the element? Is there another tool I can use to inspect the render object tree? The Mac OS X version of Safari includes a Show Render Tree command in its internal Debug menu. To enable the Debug menu, use defaults write com.apple.Safari IncludeInternalDebugMenu -bool YES So, when I try this with the trunk I get an error on the console: 2010-01-21 11:17:24.288 Safari[20905:80f] *** -[WebRenderNode initWithWebFrameView:]: unrecognized selector sent to instance 0x1f930270 and nothing happens. It would be great to add more knowledge of the render tree, including anonymous renderers, to the Web Inspector! It would be never nice to be able to select an element in the web inspector and then be able to say show me the rendering tree. That would result in the tree display with that element's rendering object being selected. I would want to be able have similar information to what is displayed in the web inspector for an element. Specifically, I'd want the computed style and metrics. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Anonymous Rendering Objects in Web Inspector
On Jan 21, 2010, at 11:22 AM, Alex Milowski wrote: So, when I try this with the trunk I get an error on the console: 2010-01-21 11:17:24.288 Safari[20905:80f] *** -[WebRenderNode initWithWebFrameView:]: unrecognized selector sent to instance 0x1f930270 and nothing happens. This was broken last August by http://trac.webkit.org/changeset/46901, and won’t work with the older versions of Safari unless someone puts in a compatibility hack. The problem will go away if a major version of Safari is released. The compatibility hack would be extremely simple to add. Just add a new method named initWithWebFrameView: to the WebRenderNode.mm that goes from WebFrameView to WebFrame and then calls over to initWithWebFrame: — we can keep that in there until people have the new Safari. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] +R mode on #webkit IRC channel
Maybe it was a countermeasure for yesterday's CTCP flood attacks? Philippe On Tue, 2010-01-19 at 10:25 +0200, Xan Lopez wrote: Hi, I woke up this morning to find #webkit set up with mode +R (http://docs.dal.net/docs/modes.html#2.17), so basically you can't speak unless you have your nick registered on freenode. Is this a new policy or just some error or temporary measure that someone forgot to disable? If it's the latter it would be good to go back to normality. Cheers, Xan ___ 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] Remove underscore check in check-webkit-style?
On Thursday 14. January 2010 12.49.40 ext Kenneth Christiansen wrote: In Qt we only allow underscored in methods that start with qt_ and they are used for private API, such as for the DRT and for API that we havent had the time to API review, but are still needed by some other software products. Hi, In general it is true, but you have forgotten about q_ptr, d_ptr and *_data in Qt's autotest suite. Jędrek ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] location in the tree for third party python code?
Hi all, I'm about to upload a patch that depends on third-party python code (simplejson). The patch is a bunch of scripts that'll live under WebKitTools/Scripts . Is there an appropriate place for the simplejson code? In the absence of a better location, I'll probably check it in under WebKitTools. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] location in the tree for third party python code?
So far, things have been put in place with other files (like the python websockets code) but I think that is confusing for a number of reasons: 1. The level of review needed varies imo between 3rd party code that is being used vs new code added to wk. 2. The style never seems to match what is done for the rest of WebKit. 3. It becomes unclear how to update it because there aren't always good concise instructions about this. Personally, I'd much prefer a ThirdParty directory to check these things into which we could use to help address these things. dave On Thu, Jan 21, 2010 at 1:30 PM, Dirk Pranke dpra...@chromium.org wrote: Hi all, I'm about to upload a patch that depends on third-party python code (simplejson). The patch is a bunch of scripts that'll live under WebKitTools/Scripts . Is there an appropriate place for the simplejson code? In the absence of a better location, I'll probably check it in under WebKitTools. -- Dirk ___ 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] location in the tree for third party python code?
We also have webkitpy/autoinstall.py which knows how to download modules on-demand. This is useful in the case that you're using code with an incompatible license. see webkitpy/__init__.py for an example of how we pull in mechanize (which is a HUGE module, with a compatible license for most files, but includes a bit of code which is not compatible). On Thu, Jan 21, 2010 at 1:39 PM, David Levin le...@google.com wrote: So far, things have been put in place with other files (like the python websockets code) but I think that is confusing for a number of reasons: 1. The level of review needed varies imo between 3rd party code that is being used vs new code added to wk. 2. The style never seems to match what is done for the rest of WebKit. 3. It becomes unclear how to update it because there aren't always good concise instructions about this. Personally, I'd much prefer a ThirdParty directory to check these things into which we could use to help address these things. dave On Thu, Jan 21, 2010 at 1:30 PM, Dirk Pranke dpra...@chromium.org wrote: Hi all, I'm about to upload a patch that depends on third-party python code (simplejson). The patch is a bunch of scripts that'll live under WebKitTools/Scripts . Is there an appropriate place for the simplejson code? In the absence of a better location, I'll probably check it in under WebKitTools. -- Dirk ___ 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] Tagging bug names with a platform name: limit to platform-specific patches
Just want to add my two cents. Based on my own experience, I think a patch that targets to fix a platform-specific problem but ends up making changes in platform-independent code, often means either the fix is problematic or a new bug/test case needs to be created for the independent part only. Chang -Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of ext Darin Adler Sent: Wednesday, January 20, 2010 11:19 AM To: WebKit Development Subject: [webkit-dev] Tagging bug names with a platform name: limit to platform-specific patches Hi folks. We've never formalized this, but I believe that patches tagged with a particular platform name such as [Qt] Add new API for fluffy bunnies should be limited to one particular platform's code. If the patch changes more than a trivial bit of platform-independent code, even if the change is only for the benefit of a signle platform, I suggest we not use the platform name prefix. -- Darin ___ 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] MathML Patch - Current Code
On Thu, Jan 14, 2010 at 8:23 PM, Alex Milowski a...@milowski.org wrote: I plan on creating smaller patches that contain code from this patch and as that gets committed, I'll update this bug with a new patch against the trunk. Here's my first patch that splits off some of the basic setup: https://bugs.webkit.org/show_bug.cgi?id=33964 There really isn't any rendering code in here yet. Anyone up for a review? -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] location in the tree for third party python code?
This page makes it looks like we can just autoinstall simplejson: http://pypi.python.org/pypi/simplejson/ IMHO, that's better than checking it in. Adam On Thu, Jan 21, 2010 at 1:58 PM, Eric Seidel e...@webkit.org wrote: We also have webkitpy/autoinstall.py which knows how to download modules on-demand. This is useful in the case that you're using code with an incompatible license. see webkitpy/__init__.py for an example of how we pull in mechanize (which is a HUGE module, with a compatible license for most files, but includes a bit of code which is not compatible). On Thu, Jan 21, 2010 at 1:39 PM, David Levin le...@google.com wrote: So far, things have been put in place with other files (like the python websockets code) but I think that is confusing for a number of reasons: 1. The level of review needed varies imo between 3rd party code that is being used vs new code added to wk. 2. The style never seems to match what is done for the rest of WebKit. 3. It becomes unclear how to update it because there aren't always good concise instructions about this. Personally, I'd much prefer a ThirdParty directory to check these things into which we could use to help address these things. dave On Thu, Jan 21, 2010 at 1:30 PM, Dirk Pranke dpra...@chromium.org wrote: Hi all, I'm about to upload a patch that depends on third-party python code (simplejson). The patch is a bunch of scripts that'll live under WebKitTools/Scripts . Is there an appropriate place for the simplejson code? In the absence of a better location, I'll probably check it in under WebKitTools. -- Dirk ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Build bots
It seems gtk and qt build bots are never for run for 33937. Do I need to do something here? https://bugs.webkit.org/show_bug.cgi?id=33937 Regards, Kwang Yul Seo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] location in the tree for third party python code?
Autoinstall appears to be pretty flaky for me at the moment, and these aren't the sort of scripts that can be flaky :) I'll install simplejson into WebKitTools/simplejson as part of the patch and we can clean it up once things are stable. -- Dirk On Thu, Jan 21, 2010 at 2:45 PM, Eric Seidel e...@webkit.org wrote: Be aware, there are a couple known issues with our current autoinstall setup: https://bugs.webkit.org/show_bug.cgi?id=33632 https://bugs.webkit.org/show_bug.cgi?id=33365 On Thu, Jan 21, 2010 at 2:35 PM, Adam Barth aba...@webkit.org wrote: This page makes it looks like we can just autoinstall simplejson: http://pypi.python.org/pypi/simplejson/ IMHO, that's better than checking it in. Adam On Thu, Jan 21, 2010 at 1:58 PM, Eric Seidel e...@webkit.org wrote: We also have webkitpy/autoinstall.py which knows how to download modules on-demand. This is useful in the case that you're using code with an incompatible license. see webkitpy/__init__.py for an example of how we pull in mechanize (which is a HUGE module, with a compatible license for most files, but includes a bit of code which is not compatible). On Thu, Jan 21, 2010 at 1:39 PM, David Levin le...@google.com wrote: So far, things have been put in place with other files (like the python websockets code) but I think that is confusing for a number of reasons: 1. The level of review needed varies imo between 3rd party code that is being used vs new code added to wk. 2. The style never seems to match what is done for the rest of WebKit. 3. It becomes unclear how to update it because there aren't always good concise instructions about this. Personally, I'd much prefer a ThirdParty directory to check these things into which we could use to help address these things. dave On Thu, Jan 21, 2010 at 1:30 PM, Dirk Pranke dpra...@chromium.org wrote: Hi all, I'm about to upload a patch that depends on third-party python code (simplejson). The patch is a bunch of scripts that'll live under WebKitTools/Scripts . Is there an appropriate place for the simplejson code? In the absence of a better location, I'll probably check it in under WebKitTools. -- Dirk ___ 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 ___ 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] location in the tree for third party python code?
According to that site, the package is available under: License :: OSI Approved :: MIT License Is that compatible with being landed in the svn.webkit.org tree? Adam On Thu, Jan 21, 2010 at 5:58 PM, Dirk Pranke dpra...@chromium.org wrote: Autoinstall appears to be pretty flaky for me at the moment, and these aren't the sort of scripts that can be flaky :) I'll install simplejson into WebKitTools/simplejson as part of the patch and we can clean it up once things are stable. -- Dirk On Thu, Jan 21, 2010 at 2:45 PM, Eric Seidel e...@webkit.org wrote: Be aware, there are a couple known issues with our current autoinstall setup: https://bugs.webkit.org/show_bug.cgi?id=33632 https://bugs.webkit.org/show_bug.cgi?id=33365 On Thu, Jan 21, 2010 at 2:35 PM, Adam Barth aba...@webkit.org wrote: This page makes it looks like we can just autoinstall simplejson: http://pypi.python.org/pypi/simplejson/ IMHO, that's better than checking it in. Adam On Thu, Jan 21, 2010 at 1:58 PM, Eric Seidel e...@webkit.org wrote: We also have webkitpy/autoinstall.py which knows how to download modules on-demand. This is useful in the case that you're using code with an incompatible license. see webkitpy/__init__.py for an example of how we pull in mechanize (which is a HUGE module, with a compatible license for most files, but includes a bit of code which is not compatible). On Thu, Jan 21, 2010 at 1:39 PM, David Levin le...@google.com wrote: So far, things have been put in place with other files (like the python websockets code) but I think that is confusing for a number of reasons: 1. The level of review needed varies imo between 3rd party code that is being used vs new code added to wk. 2. The style never seems to match what is done for the rest of WebKit. 3. It becomes unclear how to update it because there aren't always good concise instructions about this. Personally, I'd much prefer a ThirdParty directory to check these things into which we could use to help address these things. dave On Thu, Jan 21, 2010 at 1:30 PM, Dirk Pranke dpra...@chromium.org wrote: Hi all, I'm about to upload a patch that depends on third-party python code (simplejson). The patch is a bunch of scripts that'll live under WebKitTools/Scripts . Is there an appropriate place for the simplejson code? In the absence of a better location, I'll probably check it in under WebKitTools. -- Dirk ___ 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 ___ 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] location in the tree for third party python code?
To make things simpler when upstreaming, lets start by just requiring users have simplejson installed to use run-chromium-webkit-tests. I can fix the autoinstall stuff later. On Thu, Jan 21, 2010 at 6:01 PM, Adam Barth aba...@webkit.org wrote: According to that site, the package is available under: License :: OSI Approved :: MIT License Is that compatible with being landed in the svn.webkit.org tree? Adam On Thu, Jan 21, 2010 at 5:58 PM, Dirk Pranke dpra...@chromium.org wrote: Autoinstall appears to be pretty flaky for me at the moment, and these aren't the sort of scripts that can be flaky :) I'll install simplejson into WebKitTools/simplejson as part of the patch and we can clean it up once things are stable. -- Dirk On Thu, Jan 21, 2010 at 2:45 PM, Eric Seidel e...@webkit.org wrote: Be aware, there are a couple known issues with our current autoinstall setup: https://bugs.webkit.org/show_bug.cgi?id=33632 https://bugs.webkit.org/show_bug.cgi?id=33365 On Thu, Jan 21, 2010 at 2:35 PM, Adam Barth aba...@webkit.org wrote: This page makes it looks like we can just autoinstall simplejson: http://pypi.python.org/pypi/simplejson/ IMHO, that's better than checking it in. Adam On Thu, Jan 21, 2010 at 1:58 PM, Eric Seidel e...@webkit.org wrote: We also have webkitpy/autoinstall.py which knows how to download modules on-demand. This is useful in the case that you're using code with an incompatible license. see webkitpy/__init__.py for an example of how we pull in mechanize (which is a HUGE module, with a compatible license for most files, but includes a bit of code which is not compatible). On Thu, Jan 21, 2010 at 1:39 PM, David Levin le...@google.com wrote: So far, things have been put in place with other files (like the python websockets code) but I think that is confusing for a number of reasons: 1. The level of review needed varies imo between 3rd party code that is being used vs new code added to wk. 2. The style never seems to match what is done for the rest of WebKit. 3. It becomes unclear how to update it because there aren't always good concise instructions about this. Personally, I'd much prefer a ThirdParty directory to check these things into which we could use to help address these things. dave On Thu, Jan 21, 2010 at 1:30 PM, Dirk Pranke dpra...@chromium.org wrote: Hi all, I'm about to upload a patch that depends on third-party python code (simplejson). The patch is a bunch of scripts that'll live under WebKitTools/Scripts . Is there an appropriate place for the simplejson code? In the absence of a better location, I'll probably check it in under WebKitTools. -- Dirk ___ 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 ___ 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] location in the tree for third party python code?
I didn't see a web page about it, but when you submit a patch, every single bullet mentions only BSD or LGPL 2.1 is accepted. If you are sending in a patch to existing WebKit code, you agree by clicking below that your changes are licensed under the existing license terms of the file you are modifying (i.e., BSD license or GNU Lesser General Public License v.2.1, LGPL v. 2.1). Please also add your copyright (name and year) to the relevant files for changes that are more than 10 lines of code. If you are sending in a new file for inclusion in WebKit (no code copied from another source), the preferred license is BSD, but LGPL 2.1 is an option as well. Please include your copyright (name and year) and license preference (BSD or LGPL 2.1). By clicking below you agree that your file is licensed under either the BSD license or LGPL 2.1, as indicated in your file. If you aren't the author of the patch, you agree to include the original copyright notices and licensing terms with it, to the extent that they exist. If there wasn't a copyright notice or license, please make a note of it. Generally we can only take in patches that are BSD- or LGPL-licensed in order to maintain license compatibility within the project. On Thu, Jan 21, 2010 at 6:01 PM, Adam Barth aba...@webkit.org wrote: According to that site, the package is available under: License :: OSI Approved :: MIT License Is that compatible with being landed in the svn.webkit.org tree? Adam On Thu, Jan 21, 2010 at 5:58 PM, Dirk Pranke dpra...@chromium.org wrote: Autoinstall appears to be pretty flaky for me at the moment, and these aren't the sort of scripts that can be flaky :) I'll install simplejson into WebKitTools/simplejson as part of the patch and we can clean it up once things are stable. -- Dirk On Thu, Jan 21, 2010 at 2:45 PM, Eric Seidel e...@webkit.org wrote: Be aware, there are a couple known issues with our current autoinstall setup: https://bugs.webkit.org/show_bug.cgi?id=33632 https://bugs.webkit.org/show_bug.cgi?id=33365 On Thu, Jan 21, 2010 at 2:35 PM, Adam Barth aba...@webkit.org wrote: This page makes it looks like we can just autoinstall simplejson: http://pypi.python.org/pypi/simplejson/ IMHO, that's better than checking it in. Adam On Thu, Jan 21, 2010 at 1:58 PM, Eric Seidel e...@webkit.org wrote: We also have webkitpy/autoinstall.py which knows how to download modules on-demand. This is useful in the case that you're using code with an incompatible license. see webkitpy/__init__.py for an example of how we pull in mechanize (which is a HUGE module, with a compatible license for most files, but includes a bit of code which is not compatible). On Thu, Jan 21, 2010 at 1:39 PM, David Levin le...@google.com wrote: So far, things have been put in place with other files (like the python websockets code) but I think that is confusing for a number of reasons: 1. The level of review needed varies imo between 3rd party code that is being used vs new code added to wk. 2. The style never seems to match what is done for the rest of WebKit. 3. It becomes unclear how to update it because there aren't always good concise instructions about this. Personally, I'd much prefer a ThirdParty directory to check these things into which we could use to help address these things. dave On Thu, Jan 21, 2010 at 1:30 PM, Dirk Pranke dpra...@chromium.org wrote: Hi all, I'm about to upload a patch that depends on third-party python code (simplejson). The patch is a bunch of scripts that'll live under WebKitTools/Scripts . Is there an appropriate place for the simplejson code? In the absence of a better location, I'll probably check it in under WebKitTools. -- Dirk ___ 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 ___ 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] location in the tree for third party python code?
The MIT license is equivalent to the standard no-advertising-clause BSD license that we use in WebKit. It would be acceptable. - Maciej On Jan 21, 2010, at 6:11 PM, David Levin wrote: I didn't see a web page about it, but when you submit a patch, every single bullet mentions only BSD or LGPL 2.1 is accepted. If you are sending in a patch to existing WebKit code, you agree by clicking below that your changes are licensed under the existing license terms of the file you are modifying (i.e., BSD license or GNU Lesser General Public License v.2.1, LGPL v. 2.1). Please also add your copyright (name and year) to the relevant files for changes that are more than 10 lines of code. If you are sending in a new file for inclusion in WebKit (no code copied from another source), the preferred license is BSD, but LGPL 2.1 is an option as well. Please include your copyright (name and year) and license preference (BSD or LGPL 2.1). By clicking below you agree that your file is licensed under either the BSD license or LGPL 2.1, as indicated in your file. If you aren't the author of the patch, you agree to include the original copyright notices and licensing terms with it, to the extent that they exist. If there wasn't a copyright notice or license, please make a note of it. Generally we can only take in patches that are BSD- or LGPL-licensed in order to maintain license compatibility within the project. On Thu, Jan 21, 2010 at 6:01 PM, Adam Barth aba...@webkit.org wrote: According to that site, the package is available under: License :: OSI Approved :: MIT License Is that compatible with being landed in the svn.webkit.org tree? Adam On Thu, Jan 21, 2010 at 5:58 PM, Dirk Pranke dpra...@chromium.org wrote: Autoinstall appears to be pretty flaky for me at the moment, and these aren't the sort of scripts that can be flaky :) I'll install simplejson into WebKitTools/simplejson as part of the patch and we can clean it up once things are stable. -- Dirk On Thu, Jan 21, 2010 at 2:45 PM, Eric Seidel e...@webkit.org wrote: Be aware, there are a couple known issues with our current autoinstall setup: https://bugs.webkit.org/show_bug.cgi?id=33632 https://bugs.webkit.org/show_bug.cgi?id=33365 On Thu, Jan 21, 2010 at 2:35 PM, Adam Barth aba...@webkit.org wrote: This page makes it looks like we can just autoinstall simplejson: http://pypi.python.org/pypi/simplejson/ IMHO, that's better than checking it in. Adam On Thu, Jan 21, 2010 at 1:58 PM, Eric Seidel e...@webkit.org wrote: We also have webkitpy/autoinstall.py which knows how to download modules on-demand. This is useful in the case that you're using code with an incompatible license. see webkitpy/__init__.py for an example of how we pull in mechanize (which is a HUGE module, with a compatible license for most files, but includes a bit of code which is not compatible). On Thu, Jan 21, 2010 at 1:39 PM, David Levin le...@google.com wrote: So far, things have been put in place with other files (like the python websockets code) but I think that is confusing for a number of reasons: 1. The level of review needed varies imo between 3rd party code that is being used vs new code added to wk. 2. The style never seems to match what is done for the rest of WebKit. 3. It becomes unclear how to update it because there aren't always good concise instructions about this. Personally, I'd much prefer a ThirdParty directory to check these things into which we could use to help address these things. dave On Thu, Jan 21, 2010 at 1:30 PM, Dirk Pranke dpra...@chromium.org wrote: Hi all, I'm about to upload a patch that depends on third-party python code (simplejson). The patch is a bunch of scripts that'll live under WebKitTools/Scripts . Is there an appropriate place for the simplejson code? In the absence of a better location, I'll probably check it in under WebKitTools. -- Dirk ___ 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 ___ 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
Re: [webkit-dev] Tagging bug names with a platform name: limit to platform-specific patches
On Jan 21, 2010, at 3:37 AM, Anton Muhin wrote: On Thu, Jan 21, 2010 at 10:58 AM, Maciej Stachowiak m...@apple.com wrote: On Jan 20, 2010, at 8:18 AM, Darin Adler wrote: Hi folks. We’ve never formalized this, but I believe that patches tagged with a particular platform name such as [Qt] Add new API for fluffy bunnies should be limited to one particular platform’s code. If the patch changes more than a trivial bit of platform-independent code, even if the change is only for the benefit of a signle platform, I suggest we not use the platform name prefix. Makes sense to me. I would also like to suggest that people should *not* use the bracket convention for things besides platform, like [dom] or [style-queue]. Some people (e.g. me) use queries to split bracket-prefix patches into a separate list, and it's better not to hide general-purpose patches. Sorry for using those, tried to be a good citizen :) Should be tags like dom, v8 omitted completely or is there some other way to communicate the system? Tagging with [v8] is fine since that's essentially a port-specific component that many reviewers are not knowledgable about. But [dom] is not necessary. If you wan to indicate the component, you can use the component field in the bug. Or just mention the DOM in the bug title. It's not super important either way. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] ENABLE(SINGLE_THREADED)
Hi, Currently, ENABLE(SINGLE_THREADED) guard seems to be used by Qt alone. I think it is good to have ENABLE(SINGLE_THREADED) for other ports. Qt adds appropriate guards for ENABLE(SINGLE_THREADED) in the build script, WebKit.pri. For other ports to use it, we need to move theses guards to Platform.h: #if ENABLE(SINGLE_THREADED) #undef ENABLE_JSC_MULTIPLE_THREADS #define ENABLE_JSC_MULTIPLE_THREADS 0 #define ENABLE_DATABASE 0 #define ENABLE_DOM_STORAGE 0 #define ENABLE_ICONDATABASE 0 #define ENABLE_WORKERS 0 #define ENABLE_SHARED_WORKERS 0 #endif Is this okay for Qt port? Regards, Kwang Yul Seo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] IndexedDB API
A couple of us at Google are starting to look at implementing the IndexedDB API [1] in WebKit. We thought a good first step would be to create the IDL files. The first thing I noticed is that it and the Web SQL Database API [2] have quite a few conflicts in terms of their interface names. I'm wondering how we can work around this. One idea I had was to just add a prefix to every IndexedDB interface. Maybe something like IDB? I'd probably go ahead and give all the indexed database API files a IDB prefix just to make it clear which files are connected to that API. Does this sound good? Like I said, we're _just_ getting started. Once we've got the basics down (like the IDL files) we'll probably be writing up a design doc to get feedback on an end-to-end design and/or soliciting more advice on webkit-dev. J [1] http://www.w3.org/TR/IndexedDB/ [2] http://dev.w3.org/html5/webdatabase/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] IndexedDB API
On Jan 21, 2010, at 9:53 PM, Jeremy Orlow wrote: A couple of us at Google are starting to look at implementing the IndexedDB API [1] in WebKit. We thought a good first step would be to create the IDL files. The first thing I noticed is that it and the Web SQL Database API [2] have quite a few conflicts in terms of their interface names. I'm wondering how we can work around this. It seems like this is something that should be fixed in the IndexedDB spec. One idea I had was to just add a prefix to every IndexedDB interface. Maybe something like IDB? I'd probably go ahead and give all the indexed database API files a IDB prefix just to make it clear which files are connected to that API. Does this sound good? Even if you rename the files, having multiple interfaces with the same interface name will still cause problems. I don't think it will even compile. We could do some interim thing but we really need to get the spec fixed. Like I said, we're _just_ getting started. Once we've got the basics down (like the IDL files) we'll probably be writing up a design doc to get feedback on an end-to-end design and/or soliciting more advice on webkit-dev. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
