[webkit-dev] Windows build issue with r110420
Hi All, I am facing Windows build issue with r110420 for some files, the errors are as mentioned below \RenderThemeSafari.cpp(43) : fatal error C1083: Cannot open include file: 'RetainPtr.h': source\webcore\platform\graphics\win\UniscribeController.h(32) : fatal error C1083: Cannot open include file: 'Vector.h': I found that these are WTF headers are present inside ./Debug/include/private/JavaScriptCore/wtf/RetainPtr.h In all the files, where the problem is reported are including the header files as RetainPtr.h where from the above include path, it should be wtf/RetainPtr.h = this is how in most of the files the header file is included. Therefore, I think this is a valid issue. If anyone can please comment on this, I can submit a patch for this. BTW, after changing the include file as mentioned, my build went through. Regs, Rahaman ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Windows build issue with r110420
Hi All, I just noticed that in the latest revision r110541, these errors are fixed in the same way discussed below. So, someone must have fixed this in later revision. Sorry for spamming L Regs, Rahaman From: M Rahaman [mailto:mraha...@innominds.com] Sent: Tuesday, March 13, 2012 11:54 AM To: webkit-dev@lists.webkit.org Subject: Windows build issue with r110420 Hi All, I am facing Windows build issue with r110420 for some files, the errors are as mentioned below \RenderThemeSafari.cpp(43) : fatal error C1083: Cannot open include file: 'RetainPtr.h': source\webcore\platform\graphics\win\UniscribeController.h(32) : fatal error C1083: Cannot open include file: 'Vector.h': I found that these are WTF headers are present inside ./Debug/include/private/JavaScriptCore/wtf/RetainPtr.h In all the files, where the problem is reported are including the header files as RetainPtr.h where from the above include path, it should be wtf/RetainPtr.h = this is how in most of the files the header file is included. Therefore, I think this is a valid issue. If anyone can please comment on this, I can submit a patch for this. BTW, after changing the include file as mentioned, my build went through. Regs, Rahaman ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Separating ENABLE(NOTIFICATIONS) and ENABLE(LEGACY_NOTIFICATIONS)
Jon, could you please provide what are going to be included in LEGACY_NOTIFICATIONS? Does LEGACY_NOTIFICATION only includes HTML notification and old syntax we're considering to deprecate? Jian On Mon, Mar 12, 2012 at 7:11 PM, Adam Barth aba...@webkit.org wrote: That sounds like a good approach. Chromium will likely need to remember to disable NOTIFICATIONS on any upcoming release branches (until the work is complete). Adam On Mon, Mar 12, 2012 at 6:58 PM, Jon Lee jon...@apple.com wrote: Hi WebKit! In order to ease the migration path for the nascent notifications API, I'd like to separate the current dependency between NOTIFICATION and LEGACY_NOTIFICATIONS. Currently, in order to support the legacy API, both defines are needed, but ends up also including the new API. Since the future is to eventually move to the spec'd API, I like to separate the two defines, so that NOTIFICATIONS covers the new API, and LEGACY_NOTIFICATIONS the previous one. Currently all ports that support notifications will support both. https://bugs.webkit.org/show_bug.cgi?id=80922 tracks the work, and once the patch lands, ports that wish to avoid exposing the new API should remove the NOTIFICATION define. Any concerns? Thanks, Jon ___ 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] Separating ENABLE(NOTIFICATIONS) and ENABLE(LEGACY_NOTIFICATIONS)
LEGACY_NOTIFICATIONS, for the most part, is exactly what NOTIFICATIONS covers now. So yes, it includes HTML notifications and old syntax, and will not remove anything that already exists. Jon On Mar 13, 2012, at 1:25 PM, Jian Li jia...@chromium.org wrote: Jon, could you please provide what are going to be included in LEGACY_NOTIFICATIONS? Does LEGACY_NOTIFICATION only includes HTML notification and old syntax we're considering to deprecate? Jian On Mon, Mar 12, 2012 at 7:11 PM, Adam Barth aba...@webkit.org wrote: That sounds like a good approach. Chromium will likely need to remember to disable NOTIFICATIONS on any upcoming release branches (until the work is complete). Adam On Mon, Mar 12, 2012 at 6:58 PM, Jon Lee jon...@apple.com wrote: Hi WebKit! In order to ease the migration path for the nascent notifications API, I'd like to separate the current dependency between NOTIFICATION and LEGACY_NOTIFICATIONS. Currently, in order to support the legacy API, both defines are needed, but ends up also including the new API. Since the future is to eventually move to the spec'd API, I like to separate the two defines, so that NOTIFICATIONS covers the new API, and LEGACY_NOTIFICATIONS the previous one. Currently all ports that support notifications will support both. https://bugs.webkit.org/show_bug.cgi?id=80922 tracks the work, and once the patch lands, ports that wish to avoid exposing the new API should remove the NOTIFICATION define. Any concerns? Thanks, Jon ___ 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] Separating ENABLE(NOTIFICATIONS) and ENABLE(LEGACY_NOTIFICATIONS)
What will NOTIFICATIONS cover after LEGACY_NOTIFICATIONS is being added? Does it cover new syntax only or any syntax that are not considered old? Jian On Tue, Mar 13, 2012 at 1:29 PM, Jon Lee jon...@apple.com wrote: LEGACY_NOTIFICATIONS, for the most part, is exactly what NOTIFICATIONS covers now. So yes, it includes HTML notifications and old syntax, and will not remove anything that already exists. Jon On Mar 13, 2012, at 1:25 PM, Jian Li jia...@chromium.org wrote: Jon, could you please provide what are going to be included in LEGACY_NOTIFICATIONS? Does LEGACY_NOTIFICATION only includes HTML notification and old syntax we're considering to deprecate? Jian On Mon, Mar 12, 2012 at 7:11 PM, Adam Barth aba...@webkit.org wrote: That sounds like a good approach. Chromium will likely need to remember to disable NOTIFICATIONS on any upcoming release branches (until the work is complete). Adam On Mon, Mar 12, 2012 at 6:58 PM, Jon Lee jon...@apple.com wrote: Hi WebKit! In order to ease the migration path for the nascent notifications API, I'd like to separate the current dependency between NOTIFICATION and LEGACY_NOTIFICATIONS. Currently, in order to support the legacy API, both defines are needed, but ends up also including the new API. Since the future is to eventually move to the spec'd API, I like to separate the two defines, so that NOTIFICATIONS covers the new API, and LEGACY_NOTIFICATIONS the previous one. Currently all ports that support notifications will support both. https://bugs.webkit.org/show_bug.cgi?id=80922 tracks the work, and once the patch lands, ports that wish to avoid exposing the new API should remove the NOTIFICATION define. Any concerns? Thanks, Jon ___ 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] Separating ENABLE(NOTIFICATIONS) and ENABLE(LEGACY_NOTIFICATIONS)
It should reflect whatever is in the notification spec. In the end, when everyone has migrated to the spec, we should be able to get rid of all the #if ENABLE(LEGACY_NOTIFICATIONS) blocks. So LEGACY_NOTIFICATIONS should isolate aspects of notifications that are either replaced by a newer API, or have been removed altogether from the spec. Jon On Mar 13, 2012, at 1:38 PM, Jian Li jia...@chromium.org wrote: What will NOTIFICATIONS cover after LEGACY_NOTIFICATIONS is being added? Does it cover new syntax only or any syntax that are not considered old? Jian On Tue, Mar 13, 2012 at 1:29 PM, Jon Lee jon...@apple.com wrote: LEGACY_NOTIFICATIONS, for the most part, is exactly what NOTIFICATIONS covers now. So yes, it includes HTML notifications and old syntax, and will not remove anything that already exists. Jon On Mar 13, 2012, at 1:25 PM, Jian Li jia...@chromium.org wrote: Jon, could you please provide what are going to be included in LEGACY_NOTIFICATIONS? Does LEGACY_NOTIFICATION only includes HTML notification and old syntax we're considering to deprecate? Jian On Mon, Mar 12, 2012 at 7:11 PM, Adam Barth aba...@webkit.org wrote: That sounds like a good approach. Chromium will likely need to remember to disable NOTIFICATIONS on any upcoming release branches (until the work is complete). Adam On Mon, Mar 12, 2012 at 6:58 PM, Jon Lee jon...@apple.com wrote: Hi WebKit! In order to ease the migration path for the nascent notifications API, I'd like to separate the current dependency between NOTIFICATION and LEGACY_NOTIFICATIONS. Currently, in order to support the legacy API, both defines are needed, but ends up also including the new API. Since the future is to eventually move to the spec'd API, I like to separate the two defines, so that NOTIFICATIONS covers the new API, and LEGACY_NOTIFICATIONS the previous one. Currently all ports that support notifications will support both. https://bugs.webkit.org/show_bug.cgi?id=80922 tracks the work, and once the patch lands, ports that wish to avoid exposing the new API should remove the NOTIFICATION define. Any concerns? Thanks, Jon ___ 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] Separating ENABLE(NOTIFICATIONS) and ENABLE(LEGACY_NOTIFICATIONS)
Will LEGACY_NOTIFICATIONS cover everything that is in there right now? Hopefully host apps won't have to define both NOTIFICATIONS and LEGACY_NOTIFICATIONS to keep their current functionality since NOTIFICATIONS sounds like it will be guarding work that is in progress. dave On Tue, Mar 13, 2012 at 2:40 PM, Jon Lee jon...@apple.com wrote: It should reflect whatever is in the notification spec. In the end, when everyone has migrated to the spec, we should be able to get rid of all the #if ENABLE(LEGACY_NOTIFICATIONS) blocks. So LEGACY_NOTIFICATIONS should isolate aspects of notifications that are either replaced by a newer API, or have been removed altogether from the spec. Jon On Mar 13, 2012, at 1:38 PM, Jian Li jia...@chromium.org wrote: What will NOTIFICATIONS cover after LEGACY_NOTIFICATIONS is being added? Does it cover new syntax only or any syntax that are not considered old? Jian On Tue, Mar 13, 2012 at 1:29 PM, Jon Lee jon...@apple.com wrote: LEGACY_NOTIFICATIONS, for the most part, is exactly what NOTIFICATIONS covers now. So yes, it includes HTML notifications and old syntax, and will not remove anything that already exists. Jon On Mar 13, 2012, at 1:25 PM, Jian Li jia...@chromium.org wrote: Jon, could you please provide what are going to be included in LEGACY_NOTIFICATIONS? Does LEGACY_NOTIFICATION only includes HTML notification and old syntax we're considering to deprecate? Jian On Mon, Mar 12, 2012 at 7:11 PM, Adam Barth aba...@webkit.org wrote: That sounds like a good approach. Chromium will likely need to remember to disable NOTIFICATIONS on any upcoming release branches (until the work is complete). Adam On Mon, Mar 12, 2012 at 6:58 PM, Jon Lee jon...@apple.com wrote: Hi WebKit! In order to ease the migration path for the nascent notifications API, I'd like to separate the current dependency between NOTIFICATION and LEGACY_NOTIFICATIONS. Currently, in order to support the legacy API, both defines are needed, but ends up also including the new API. Since the future is to eventually move to the spec'd API, I like to separate the two defines, so that NOTIFICATIONS covers the new API, and LEGACY_NOTIFICATIONS the previous one. Currently all ports that support notifications will support both. https://bugs.webkit.org/show_bug.cgi?id=80922 tracks the work, and once the patch lands, ports that wish to avoid exposing the new API should remove the NOTIFICATION define. Any concerns? Thanks, Jon ___ 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] Separating ENABLE(NOTIFICATIONS) and ENABLE(LEGACY_NOTIFICATIONS)
On Tue, Mar 13, 2012 at 2:42 PM, David Levin le...@chromium.org wrote: Will LEGACY_NOTIFICATIONS cover everything that is in there right now? By in there, I meant in WebKit and what hosts have been shipping. Hopefully host apps won't have to define both NOTIFICATIONS and LEGACY_NOTIFICATIONS to keep their current functionality since NOTIFICATIONS sounds like it will be guarding work that is in progress. dave On Tue, Mar 13, 2012 at 2:40 PM, Jon Lee jon...@apple.com wrote: It should reflect whatever is in the notification spec. In the end, when everyone has migrated to the spec, we should be able to get rid of all the #if ENABLE(LEGACY_NOTIFICATIONS) blocks. So LEGACY_NOTIFICATIONS should isolate aspects of notifications that are either replaced by a newer API, or have been removed altogether from the spec. Jon On Mar 13, 2012, at 1:38 PM, Jian Li jia...@chromium.org wrote: What will NOTIFICATIONS cover after LEGACY_NOTIFICATIONS is being added? Does it cover new syntax only or any syntax that are not considered old? Jian On Tue, Mar 13, 2012 at 1:29 PM, Jon Lee jon...@apple.com wrote: LEGACY_NOTIFICATIONS, for the most part, is exactly what NOTIFICATIONS covers now. So yes, it includes HTML notifications and old syntax, and will not remove anything that already exists. Jon On Mar 13, 2012, at 1:25 PM, Jian Li jia...@chromium.org wrote: Jon, could you please provide what are going to be included in LEGACY_NOTIFICATIONS? Does LEGACY_NOTIFICATION only includes HTML notification and old syntax we're considering to deprecate? Jian On Mon, Mar 12, 2012 at 7:11 PM, Adam Barth aba...@webkit.org wrote: That sounds like a good approach. Chromium will likely need to remember to disable NOTIFICATIONS on any upcoming release branches (until the work is complete). Adam On Mon, Mar 12, 2012 at 6:58 PM, Jon Lee jon...@apple.com wrote: Hi WebKit! In order to ease the migration path for the nascent notifications API, I'd like to separate the current dependency between NOTIFICATION and LEGACY_NOTIFICATIONS. Currently, in order to support the legacy API, both defines are needed, but ends up also including the new API. Since the future is to eventually move to the spec'd API, I like to separate the two defines, so that NOTIFICATIONS covers the new API, and LEGACY_NOTIFICATIONS the previous one. Currently all ports that support notifications will support both. https://bugs.webkit.org/show_bug.cgi?id=80922 tracks the work, and once the patch lands, ports that wish to avoid exposing the new API should remove the NOTIFICATION define. Any concerns? Thanks, Jon ___ 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] Separating ENABLE(NOTIFICATIONS) and ENABLE(LEGACY_NOTIFICATIONS)
I see where the confusion is, and I misspoke. You can include either NOTIFICATIONS or LEGACY_NOTIFICATIONS and have a complete API. LEGACY_NOTIFICATIONS should cover all of the previous functionality, and NOTIFICATIONS will cover the new API. Therefore, APIs that are common between the two will have #if ENABLE(NOTIFICATIONS) || ENABLE(LEGACY_NOTIFICATIONS) The patch I am putting up for review will initially set both to be exactly the same. That is, all #if ENABLE(NOTIFICATIONS) is replaced by #if ENABLE(NOTIFICATIONS) || ENABLE(LEGACY_NOTIFICATIONS) and something similar for the .idl's. As other bugs with patches begin to migrate to the new API, the defines will begin to split. Hope that helps. Sorry about the confusion. Jon On Mar 13, 2012, at 2:42 PM, David Levin le...@chromium.org wrote: Will LEGACY_NOTIFICATIONS cover everything that is in there right now? Hopefully host apps won't have to define both NOTIFICATIONS and LEGACY_NOTIFICATIONS to keep their current functionality since NOTIFICATIONS sounds like it will be guarding work that is in progress. dave On Tue, Mar 13, 2012 at 2:40 PM, Jon Lee jon...@apple.com wrote: It should reflect whatever is in the notification spec. In the end, when everyone has migrated to the spec, we should be able to get rid of all the #if ENABLE(LEGACY_NOTIFICATIONS) blocks. So LEGACY_NOTIFICATIONS should isolate aspects of notifications that are either replaced by a newer API, or have been removed altogether from the spec. Jon On Mar 13, 2012, at 1:38 PM, Jian Li jia...@chromium.org wrote: What will NOTIFICATIONS cover after LEGACY_NOTIFICATIONS is being added? Does it cover new syntax only or any syntax that are not considered old? Jian On Tue, Mar 13, 2012 at 1:29 PM, Jon Lee jon...@apple.com wrote: LEGACY_NOTIFICATIONS, for the most part, is exactly what NOTIFICATIONS covers now. So yes, it includes HTML notifications and old syntax, and will not remove anything that already exists. Jon On Mar 13, 2012, at 1:25 PM, Jian Li jia...@chromium.org wrote: Jon, could you please provide what are going to be included in LEGACY_NOTIFICATIONS? Does LEGACY_NOTIFICATION only includes HTML notification and old syntax we're considering to deprecate? Jian On Mon, Mar 12, 2012 at 7:11 PM, Adam Barth aba...@webkit.org wrote: That sounds like a good approach. Chromium will likely need to remember to disable NOTIFICATIONS on any upcoming release branches (until the work is complete). Adam On Mon, Mar 12, 2012 at 6:58 PM, Jon Lee jon...@apple.com wrote: Hi WebKit! In order to ease the migration path for the nascent notifications API, I'd like to separate the current dependency between NOTIFICATION and LEGACY_NOTIFICATIONS. Currently, in order to support the legacy API, both defines are needed, but ends up also including the new API. Since the future is to eventually move to the spec'd API, I like to separate the two defines, so that NOTIFICATIONS covers the new API, and LEGACY_NOTIFICATIONS the previous one. Currently all ports that support notifications will support both. https://bugs.webkit.org/show_bug.cgi?id=80922 tracks the work, and once the patch lands, ports that wish to avoid exposing the new API should remove the NOTIFICATION define. Any concerns? Thanks, Jon ___ 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] GTK 32-bit Linux Release build failing after r110580 (from bug 80338)
GTK friends, After bug 80338 landed, the GTK 32-bit build bot has been failing with a linking error. Since I do not have a GTK build environment set up, I put up a speculative build fix in a new bug: https://bugs.webkit.org/show_bug.cgi?id=81063. If any GTK expert thinks this is the right fix, I would appreciate a review and cq+. The details of the situation are described in the bug. Thank you, Max ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] static build JavaScriptCore
Hi, I'm doing performance testing research of various JavaScript interpreters on a cluster of old Fedora machines. node/v8, rhino, and spidermonkey shells all work fine on these machines, but jsc, which I have been able to build on my recent Ubuntu box, is missing a shared library dependency (libicu). I was able to build an old version of JavaScriptCore from the source rpm in the Fedora repository, but it's fairly old, and crashes a lot. I'd therefore like to create a static build of a recent jsc on a newer machine, with all dependent libraries compiled in, so that I can then run a recent jsc on the old cluster machines. I'm wondering if there's a straightforward way to create a static build of jsc so that I can run jsc on these old machines, which do not have the same libraries as the machine on which jsc was built? I'd appreciate any guidance anyone can offer. Thanks, Jake ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] When should we turn on new features?
I'll add a Wiki page for the table of existing feature flags and their descriptions. On Tue, Feb 14, 2012 at 11:09, Maciej Stachowiak m...@apple.com wrote: I think we're talking about a couple of different things now: 1) Table of what the WebKit community as a whole (instead of individual point maintainers) thinks should be enabled in stable releases. This would be input to port maintainers looking to make a release. 2) Documenting what enable flags are actually on for given ports as shipped. Probably hard to gather this info, but might be useful input for the WebKit community. 3) Changing build systems to enable compiling nightly and stable versions from the same tree, so both modes are documented in trunk. Requires some coding for various build systems. I like (2) and (3), but I don't think they replace the usefulness of (1). I think the mention of the feature-table page is blending (2) and (1), which would serve different purposes. Regards, Maciej On Feb 13, 2012, at 4:21 PM, Hajime Morrita wrote: (Re-sending from the right address...) I'd +1 Adam's point. It would be great if we can do something like webkit-build --gtk --stable, webkit-build --chromium --canary or webkit-build --nightly where the script read the central configuration file and find an appropriate configuration. In this way, there would be no duplication we should maintain. Even though some ports currently don't support switches through build-webkit, we can gradually switch over to the central list-based configuration settings by, for example, generating features.gypi, FeatureDefines.xcconfig or a set of flags for autoconf. Also the feature-table page could be generated from the list. We can even start from simply generating an HTML from the machine-readable configuration file, then integrate it to each build system. Although it might be overkill, I personally prefer this kind of don't repeat youself direction. -- morrita On Tue, Feb 14, 2012 at 8:11 AM, Maciej Stachowiak m...@apple.com wrote: On Feb 13, 2012, at 1:21 PM, Ryosuke Niwa wrote: On Mon, Feb 13, 2012 at 1:02 PM, Maciej Stachowiak m...@apple.com wrote: I think you raise a good point. Another point worth mentioning is that sometimes a feature can be complete and useful in one port, but half-baked in another (for example, fullscreen API was shipped in Safari and at the same time present but non-functional in Chrome). I think in the past, port owners have made clear that they want to own the final decisions on what features are enabled in their ports. But we as a community could do better, by having a shared recommendation of what features we think should be enabled in shipping releases. In some cases, this may not match the settings on trunk, as some features may be desirable to enable for experimental builds, but not in shipping product. For features that we recommended disabling, ideally we'd identify a reason. And in some cases, those might be port-specific issues. Right. Even just having a list of new features with flag(s) to enable/disable and the status (e.g. list of outstanding bugs) on wiki page will be helpful. For example, vertical writing mode doesn't work on Windows, Chromium, etc... but port owners may not necessarily realize that the feature is enabled by default and each port needs to modify the code that draws text. I personally think such a page would be a good idea. I'd love to hear input from more folks on whether this is a good idea and what the right approach is. Cheers, Maciej ___ 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 -- TAMURA Kent Software Engineer, Google ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
