Re: [webkit-dev] Spelling document markers: Design question
On Tue, Mar 12, 2013 at 6:48 AM, Ryosuke Niwa rn...@webkit.org wrote: Thanks for the clarification. On Mon, Mar 11, 2013 at 9:35 AM, Rouslan Solomakhin rouslan+web...@chromium.org wrote: On Sun, Mar 10, 2013 at 10:47 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 7, 2013 at 2:58 PM, Rouslan Solomakhin rouslan+web...@chromium.org wrote: The contextual spellcheck in Chromium needs to identify the spellcheck request that added spelling markers to the document. What is contextual spellcheck? Contextual spellcheck in Chromium takes a sentence like The duck says quick and marks the word quick as contextually misspelled. The spellcheck would suggest quack instead of quick. Although all words are spelled correctly, the word quick makes less sense than quack in the context of that sentence. This information will be used to provide a feedback loop to the contextial spellcheck. I was thinking about adding an ID field to DocumentMarkerDescription detail. Is this a correct approach? I'm with morrita on this one but it's hard to answer this kind of a design question without understanding what you're trying to achieve. What we're trying to achieve is provide a feedback loop for the spellcheck, so it can improve the suggestions over time. For the feedback loop to work, we're going to assign unique identifiers to spellcheck results and store the identifiers in markers. When the user performs any operation on a spellcheck marker, the identifier from the marker will be used in the feedback. User operations may include Add to dictionary, Always ignore, Select suggestion X, etc. That sounds like a useful feature in general. On Mon, Mar 11, 2013 at 9:41 AM, Rouslan Solomakhin rouslan+web...@chromium.org wrote: On Sun, Mar 10, 2013 at 10:40 PM, Hajime Morrita morr...@chromium.org wrote: There are DocumentMarker, or DocumentMakerDetails. Which do you have in your mind? I had DocumentMarkerDetails in mind. It seems to be the standard location of auxiliary information for a document marker. Or you can possibly introduce another DocumentMakerDetails for the contextual marker. This approach might be cleaner. By introducing the new subclass, it won't interfere existing marker implementations. One caveat of this approach is that this needs extra heap allocations since DocumentMarkerDetails with unique IDs cannot be shared and will be allocated per marker. I like the approach with another DocumentMarkerDetails class. I would like to have both description and identifier in my DocumentMarkerDetails. Would it be OK to inherit from DocumentMarkerDescription? I'd rather not add another subclass. That's even worse than modifying DocumentMarkerDetails IMO because this new subclass of DocumentMarkerDetails can't be shared among multiple markers. It seems okay for each DocumentMarker to directly have an identifier although we might want to if-def it depending on how big that identifier is. On the other hand, if the ID is assigned per spellcheck request, not per word, it can be shared in the requested sentence. So the overhead won't that big. Also, API surface on DocumentMarkerController will be suffered by the change, especially if we ifdef it. Considering that the contextual spell checking (not grammatical checking) is virtually a chromium only feature, it might be better to let the complexity cost small by just extending DocumentMarkerDetails. I'm fine with either way though. There isn't big difference here. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Spelling document markers: Design question
There are DocumentMarker, or DocumentMakerDetails. Which do you have in your mind? For me, it seems DocumentMarker is the right place to put such an ID since DocumentMarkerDetails is an immutable, shared object and giving such ID breaks the assumption for instance sharing. Or you can possibly introduce another DocumentMakerDetails for the contextual marker. This approach might be cleaner. By introducing the new subclass, it won't interfere existing marker implementations. One caveat of this approach is that this needs extra heap allocations since DocumentMarkerDetails with unique IDs cannot be shared and will be allocated per marker. Sorry for my slow response. Hope this helps. On Fri, Mar 8, 2013 at 7:58 AM, Rouslan Solomakhin rouslan+web...@chromium.org wrote: Howdy folks, The contextual spellcheck in Chromium needs to identify the spellcheck request that added spelling markers to the document. This information will be used to provide a feedback loop to the contextial spellcheck. I was thinking about adding an ID field to DocumentMarkerDescription detail. Is this a correct approach? Thank you all for thoughts and suggestions! Cheers, Rouslan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Perf Monitor (perf.webkit.org) has been launched
Yay, it finally arrived! I can see graphs only for html5-full-render test. Could we have links for other test charts? Or aren't they ready yet? On Mon, Feb 25, 2013 at 12:24 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi all, We've replaced webkit-perf.appspot.com by perf.webkit.org. webkit-perf.appspot.com will be phased-out in the coming weeks. I'm going to check in the source code of perf.webkit.org into WebKit repository in coming months. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Perf Monitor (perf.webkit.org) has been launched
On Mon, Feb 25, 2013 at 1:32 PM, Ryosuke Niwa rn...@webkit.org wrote: On Sun, Feb 24, 2013 at 7:56 PM, Hajime Morrita morr...@chromium.orgwrote: Yay, it finally arrived! I can see graphs only for html5-full-render test. Could we have links for other test charts? Or aren't they ready yet? You can look at each graph on Charts page. Got it. Thanks! - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] AncestorChainWalker substance and style thoughts
On Wed, Feb 20, 2013 at 4:29 AM, Dimitri Glazkov dglaz...@chromium.orgwrote: On Tue, Feb 19, 2013 at 3:50 AM, Antti Koivisto koivi...@iki.fi wrote: The problem with ComposedShadowTreeWalker is not that it is an iterator but that it is ill-defined and complex. It calls back to non-trivial, mutating functions on the structure being traversed (ContentDistributor::distribute!). Simply traversing a tree with it can apparently end up marking the tree for style recalc. This is a really good point. It encapsulates traversal of the composed tree, but this tree's integrity is maintained lazily, which means that as you traverse it, you could force the update. That ain't awesome. We could possibly separate the recalculation of the composed tree from style recalculation or attachment. Even though the valid tree is computed lazily, the invalidation happens eagerly, which triggers style recalculation. So we could let our style recalc lifecycle to handle it and make distribute() to focus on calculating distribution. This kind of clarification is apparently worth trying, an I believe current design is close to that shape. Filed http://wkb.ug/110280 for tracking. -- morrita :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] AncestorChainWalker substance and style thoughts
AncestorChainWalker follows the style of ComposedShadowTreeWalker, which also breaks conventions like mutations-should-be-verbs. We also fix its style for integrity. Non-trivial tree traversal API in general should, IMO, be modeled after recently introduced NodeTraversal. Having separate namespaces allows us to keep Node API minimal. Also it is stateless and simple. I made NodeRenderingTraversal in that way. AncestorChainWalker could be just merged to NodeRenderingTraversal. Speaking of ComposedShadowTreeWalker, I think it is worth having a class instead of namespace since it holds configuration parameters to decide, for example, whether it skips specific types of node. On Tue, Feb 19, 2013 at 10:37 AM, Darin Adler da...@apple.com wrote: I am trying to learn about code related to shadow DOM that needs to be understood by anyone working on an part of the DOM. I have some questions and concerns about AncestorChainWalker. If there is a document I should be reading that covers these, please point me to it. The parentNode and parentElement functions are just plain old functions that are used to walk the ancestor chain of the normal DOM. But the shadow DOM AncestorChainWalker is a class. Why? It seems that it could just be a function with two return values. Is it more efficient to have it be a class? Can the operation be correctly done without storing m_distributedNode in a data member? There is a function in AncestorChainWalker named parent. That name is a noun, so the function should be a const function that returns a value. Since it’s not, the function name should be a verb phrase, such as advanceToParent, or event just “advance” since it’s in the context of an ancestor chain walker. The function crossingInsertionPoint should be named isCrossingInsertionPoint as the data member is. But also, since the walker sits still on a single node, I don’t think it makes sense to talk about the position as “is crossing”. It should be “just crossed” or something like that instead. Unless an insertion point is like a bridge and is not itself a “true node”. The function that returns the current node in the ancestor chain is named “get”. That’s not a good name, and should be avoided if possible. It could be named “node” or “currentNode” instead. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] AncestorChainWalker substance and style thoughts
AncestorChainWalker follows the style of ComposedShadowTreeWalker, which also breaks conventions like mutations-should-be-verbs. We also fix its style for integrity. We *should*. It is yet to be done :-/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Using ninja (was Re:Common build system (was Re: WebKit Wishes))
Editing seems OK if we use GYP or CMake. You can generate both Xcode and Ninja files against same source tree. Debugging won't work though, at least for GYP-generated projects. Its Ninja and Xcode builds have different directly structure. If Xcode can attach gdb/llldb to an out-of-project executable for debugging, it might work. The dwarf debug metadata points the same source code after all. But I have no idea whether it is possible. -- morrita On Tue, Feb 5, 2013 at 5:25 AM, Dirk Pranke dpra...@chromium.org wrote: The short answer is, you can't. The fastest path is probably to get a working set of gyp files for the apple mac wk2. I'm going to start working on this just to see how far of we are (Adam's work from a year or two ago had JSC and WebCore building, but wasn't too functional beyond that; even so, it's probably a good starting point). -- Dirk On Sun, Feb 3, 2013 at 1:22 PM, Dean Jackson d...@apple.com wrote: OK, this sounds fantastic. And I've noticed how much faster Chromium incrementally builds using ninja when I've done that. So, ignoring the discussion of a single build system for a moment, how can I, as a developer using the OS X + WK2 port, living mostly in Xcode for editing and debugging, use ninja? I need the idiot's guide :) (Note: I am an idiot, but not so much an idiot to realise that the answer involves lots of work and probably updating some old GYP files that you and Adam were testing with, etc etc. I'm just selfishly thinking that cutting even 30s off each incremental rebuild would make me so much happier that I'd be willing to put up with other inconveniences.) Dean On 03/02/2013, at 4:54 PM, Eric Seidel e...@webkit.org wrote: +1 Ninja is beyond-words amazing. http://martine.github.com/ninja/ For better or worse, it is not designed to use human-editable build files, but rather to be used by a meta build system, like GYP or CMake. So using ninja is really an orthogonal discussion to the single build system discussion for WebKit. :) Were the WebKit project to convert to using a single meta-build system, ninja would become an option many users might choose. I'm told most Chromium hackers have GYP set to output ninja files these days, with the exception of some folks who still want the MSVC build environment. For WebKit ports already using CMake, they should definitely try ninja today! Anyway, my wish was not about arguing for a specific build solution. I'm instead noting that for the project to continue to move quickly, we need to stop needing to edit 8 build systems for every file move/addition. Whether that's GYP or CMake or something else, I don't really care. Adam and I tried GYP-for-WebKIt a while back. But any of these solutions will require buy-in from Apple, as they will have to do the largest amount of work converting to use something other than XCode. On Sat, Feb 2, 2013 at 8:20 PM, Nico Weber tha...@chromium.org wrote: On Sat, Feb 2, 2013 at 4:58 PM, Adam Barth aba...@webkit.org wrote: Ninja has extremely fast incremental builds and can be generated by GYP. Here are some stats from a year ago: https://plus.google.com/101038813433650812235/posts/irc26fhRtPC Ninja has gotten even faster since then. If you're interested in trying it out, you can play around with incremental builds of the Chromium port on Mac or Linux. You can also look at the build output from the chromium bots. Empty build in 1s: http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/66807/steps/compile-webkit/logs/stdio Build with a few files changed in 15s: http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/66800/steps/compile-webkit/logs/stdio …and this is on fairly slow bots. On my SSD-equipped laptop, I can do incremental rebuilds of all of chrome after touching one (cpp or mm) file in 2-6s. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))
(From the right address) I did it for WTF and JSC with kevino@. https://bugs.webkit.org/show_bug.cgi?id=72855 I hope I had had time to extend the work to WebCore, which was my original goal :-/ I did it through an automation but the tool was so slow and hacky that it was not capable for large WebCore codebase. Seeing that the number of exported symbol is about 2700, manual work with regular expression will also work if it is OK to do the work incrementally... and if you are patient enough :-) -- morrita On Thu, Jan 31, 2013 at 4:39 PM, Ryosuke Niwa ryosuke.n...@gmail.comwrote: On Wed, Jan 30, 2013 at 11:33 PM, Jochen Eisinger joc...@chromium.orgwrote: On Thu, Jan 31, 2013 at 1:15 AM, Maciej Stachowiak m...@apple.com wrote: On Jan 30, 2013, at 3:24 PM, Dirk Pranke dpra...@chromium.org wrote: On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo fpi...@apple.com wrote: Thanks for sharing this. On Jan 30, 2013, at 1:28 PM, Eric Seidel e...@webkit.org wrote: I wish we only had one build system (it were easy to add/remove/move files). I believe changes like http://trac.webkit.org/changeset/74849 are an unhealthy sign for the project. Adam is not the only person who has chosen to empty files instead of removing them. The pain of updating 8 build system is so great, we jump through hoops to avoid it. Which means it took us months to move JavaScriptCore/wtf to WTF, and will take us years to kill WebCore/platform. +1 This is a hard problem. It is a problem worth solving. Do you have more thoughts on this, particularly since you know quite well how both Xcode and gyp work? I suspect this is one of those things that it would be hard to achieve consensus on since there are so many stakeholders. But it may be fruitful to have a what if discussion about what this might look like. I think we can solve this problem if we agree that we want to. I think we haven't in the past mostly because we couldn't reach a consensus that it was worth solving enough to really try. I would love to see this fixed and would be glad to work on it. I think we should at least pursue this far enough to fully understand what our options are and what the costs and tradeoffs might be; does anyone disagree, and is anyone else willing to help pitch in? I think there are several possible ways we could solve this. One would be to switch to a common meta-build system. My understanding is that Apple's internal production build processes impose certain constraints here that I don't fully understand, but I know we've discussed the possibility of checking in generated project files as a workaround. Maybe there are other options as well to those constraints? I would love to discuss this further w/ someone from Apple ... It's far simplest for us if: (a) There is an Xcode project (or a Makefile) that builds the Mac port checked in to source control. (b) The generated project invokes only tools that are part of the default Mac OS X install. Another desirable property would be to move to a more automatic way of handling exported symbols: Currently each port that depends on this feature has its own .exp file or similar. I think if we could move to something that would allow for changing WebCore API without having to touch all those files, e.g. by consistently using WEBCORE_EXPORT macros would be a big win morrita already did this for WTF, and it works great for us. What's blocking us from doing the same for WebCore? - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
On Thu, Jan 31, 2013 at 5:49 PM, Patrick Gansterer par...@paroga.comwrote: Hi, Am 31.01.2013 um 09:25 schrieb Mark Rowe: CMake was originally considered a non-starter for chromium since the XCode and VS projects it produced didn't look or feel like native projects. However, we've since switched to ninja for most things so I'm less sure how important this is now. I've never been a huge fan of the CMake syntax but I haven't used it enough to really have an informed opinion. Generating well-structured Xcode projects is still something that is important for any meta build system that we would consider adopting for the Mac. It would be substantially more challenging for us to support an alternative system for building our production builds. If there are substantial advantages to using ninja for engineering builds then we may wish to support both to get the best behavior in each environment. The non-natively structured Xcode projects is one thing that turned me off CMake when I looked at it in the past. I’m not sure if this has improved since then. If not, then I don’t think CMake is worth spending much time on. If you want to commit the generated projects CMake isn't an option anyway, since it uses absolute paths and also requires a cmake binary on the machine used for compiling (to support all CMake features across all generators). This tight integration is usually a big win, since the CMakeLists.txt files are part of the build system they can be changed directly in the IDE and update the project without invoking external tools. Only for my personal interest: What do you mean exactly with non-natively structured Xcode projects? CMake aims to support a native IDE feel as far as possible. Would be great if you explain that to me (off-list) to get CMake improved for XCode? Regarding (b) The generated project invokes only tools that are part of the default Mac OS X install: invoking tools that are checked into the WK repo is also possible, right, since we invoke scripts now? So, hypothetically, could we check in a copy of the ninja binary and build with that? Checking in binaries isn’t an option for us, and isn’t a particularly scalable approach anyway given the number of platforms that WebKit can build on. If we require an external tool as a dependency to build WebKit from source then we’d need to check in the source for the tool and build it prior to building WebKit proper. This obviously introduces more complexity so it would be preferable to keep the dependencies to a minimum. Maybe you can check in the ninja source and compile it during build. It only requires python (and hopefully installed build tools) to get built. In my understanding, it doesn't matter whether Apple Mac port supports ninja or not. We could use GNU make if some meta-build system is adopted because Mac OS has it installed. The problem here is that the neither CMake and GYP isn't easy to adopt for reasons discussed in this thread. My personal feeling is that we could build a simple meta build system which specifically targetsMac WebKit and XCode. It could be just a little more than a templating system which generates the list of files plus their UUIDs. The tool doesn't need to be so general like CMake/GYP. Many tricky configuration things could be in the hard-coded boilerplate. It could just focus on generating file list and UUIDs. It's something like project.pbxproj.in and its preprocessor. It won't be a direct step toward the unified build system. But we'll figure out the next step once the build is represented by a simple plain text. -- morrita -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
In my understanding, it doesn't matter whether Apple Mac port supports ninja or not. We could use GNU make if some meta-build system is adopted because Mac OS has it installed. The problem here is that the neither CMake and GYP isn't easy to adopt for reasons discussed in this thread. My personal feeling is that we could build a simple meta build system which specifically targetsMac WebKit and XCode. It could be just a little more than a templating system which generates the list of files plus their UUIDs. The tool doesn't need to be so general like CMake/GYP. Many tricky configuration things could be in the hard-coded boilerplate. It could just focus on generating file list and UUIDs. It's something like project.pbxproj.in and its preprocessor. It won't be a direct step toward the unified build system. But we'll figure out the next step once the build is represented by a simple plain text. -- morrita On Thu, Jan 31, 2013 at 5:49 PM, Patrick Gansterer par...@paroga.comwrote: Hi, Am 31.01.2013 um 09:25 schrieb Mark Rowe: CMake was originally considered a non-starter for chromium since the XCode and VS projects it produced didn't look or feel like native projects. However, we've since switched to ninja for most things so I'm less sure how important this is now. I've never been a huge fan of the CMake syntax but I haven't used it enough to really have an informed opinion. Generating well-structured Xcode projects is still something that is important for any meta build system that we would consider adopting for the Mac. It would be substantially more challenging for us to support an alternative system for building our production builds. If there are substantial advantages to using ninja for engineering builds then we may wish to support both to get the best behavior in each environment. The non-natively structured Xcode projects is one thing that turned me off CMake when I looked at it in the past. I’m not sure if this has improved since then. If not, then I don’t think CMake is worth spending much time on. If you want to commit the generated projects CMake isn't an option anyway, since it uses absolute paths and also requires a cmake binary on the machine used for compiling (to support all CMake features across all generators). This tight integration is usually a big win, since the CMakeLists.txt files are part of the build system they can be changed directly in the IDE and update the project without invoking external tools. Only for my personal interest: What do you mean exactly with non-natively structured Xcode projects? CMake aims to support a native IDE feel as far as possible. Would be great if you explain that to me (off-list) to get CMake improved for XCode? Regarding (b) The generated project invokes only tools that are part of the default Mac OS X install: invoking tools that are checked into the WK repo is also possible, right, since we invoke scripts now? So, hypothetically, could we check in a copy of the ninja binary and build with that? Checking in binaries isn’t an option for us, and isn’t a particularly scalable approach anyway given the number of platforms that WebKit can build on. If we require an external tool as a dependency to build WebKit from source then we’d need to check in the source for the tool and build it prior to building WebKit proper. This obviously introduces more complexity so it would be preferable to keep the dependencies to a minimum. Maybe you can check in the ninja source and compile it during build. It only requires python (and hopefully installed build tools) to get built. -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))
The history aside, I think it makes sense to use the export macro specifically for Mac WebCore because - As Eric mentioned, Currently only Mac and Win WebCore do WebCore/WebKit separation. Other ports like GTK or Chromium build single WebKit library which has both WebCore and WebKit API included. So we need to care about only Mac and Win for now. - Mac WebKit has relatively comprehensive feature set. It covers most of possibly exported symbols. - The Windows toolchain allows us to use both export symbols list and source-level annotation (the macro). Thus on Windows, we could use the Mac-centered export macro *and* an export symbol list which covers Win-specific exports. This means that there are unused exports on Win build, but I believe it is very few considering that Mac/Win ports has similar feature set, which targets Safari on each platform. (This might be wrong assumption though - On Mac, there are many other WebKit embedder other than Safari.) One exception is symbols exported for WebCoreTesting. Fortunately, these symbols are exactly same across ports and we can use another macro like WEBCORE_TESTING_EXPORT for that. -- morrita On Fri, Feb 1, 2013 at 9:14 AM, Eric Seidel e...@webkit.org wrote: I believe that it's a design mistake for WebCore to need to know anything about it's embedder, more than that there is a defined set of platform APIs and callbacks which it talks to (which should be the exact same for every embedder). (The export dependency dates back to the WebCore/WebKit separation, which in my recollection was done largely to be able to isolate LGPL code from the non-LGPL Mac WebKit layer.) But I believe it is a mistake that WebCore changes need to care about the possibility that different ports may export functions differently, or even worse, that different ports may need a different set of functions exported. I don't recommend using a more complicated export macro, but rather finding ways that WebCore doesn't need to care about diverging sets of exports. I believe most ports (with the exception of AppleWin/AppleMac) do not build WebCore as a separate dynamic library from WebKit, which makes exports a non-concern in the static case. In my perfect future world, WebCore would be split into many static libraries, and core-code - WebKit exports would be a non-issue. And of course, no embedder of core-code would ever expose core types, so no exports would ever need to be marked. On Thu, Jan 31, 2013 at 3:38 PM, Alexey Proskuryakov a...@webkit.org wrote: 31.01.2013, в 15:15, Dirk Pranke dpra...@chromium.org написал(а): I don't have concrete examples, and I don't know how big an effect on performance increasing the number of exports would have. It's something to keep an eye on, not a reason to avoid trying. I'm not parsing your reply properly -- avoid trying what? A common EXPORT macro that is set as appropriate by each port? Yes, you are parsing it correctly :) - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))
On Fri, Feb 1, 2013 at 10:39 AM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Jan 31, 2013 at 5:20 PM, Hajime Morrita morr...@chromium.orgwrote: The history aside, I think it makes sense to use the export macro specifically for Mac WebCore because - As Eric mentioned, Currently only Mac and Win WebCore do WebCore/WebKit separation. Other ports like GTK or Chromium build single WebKit library which has both WebCore and WebKit API included. So we need to care about only Mac and Win for now. - Mac WebKit has relatively comprehensive feature set. It covers most of possibly exported symbols. - The Windows toolchain allows us to use both export symbols list and source-level annotation (the macro). Thus on Windows, we could use the Mac-centered export macro *and* an export symbol list which covers Win-specific exports. This means that there are unused exports on Win build, but I believe it is very few considering that Mac/Win ports has similar feature set, which targets Safari on each platform. (This might be wrong assumption though - On Mac, there are many other WebKit embedder other than Safari.) One exception is symbols exported for WebCoreTesting. Fortunately, these symbols are exactly same across ports and we can use another macro like WEBCORE_TESTING_EXPORT for that. Doesn't GTK+ port also require symbol exports for WebKit2? In particular, I thought all symbols used in Internals need to be exported there. Ouch, I'm sorry for the unclear explanation. This is what I meant say as one exception above. WebCoreTesting includes Internals, which requires some exported symbols, which could be (IMO) covered by WEBCORE_TESTING_EXPORT or some separate macro. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Feature announcement: Custom Elements
Hi Maciej, Thanks for your attention! For reference: will the feature flag be comprehensive, or will parts of the implementation/scaffolding be outside the ifdef? It should be comprehensive. So it will. Although some trivial inline stubs, like just returning null or false, or even doing nothing, will be outside the flag for minimizing if/def disturbance, they'll be optimized out by compilers. Also, some kind of refactoring might precede to make new features fit in the code. Such refactoring will be aimed to achieve clear separation of new additions by, for example, introducing better encapsulation. (Please note that this is just a general direction of the change. I have no concrete refactoring plan in my mind at this time.) As an example, here is the first bit of the change: https://bugs.webkit.org/attachment.cgi?id=185411action=review I expect most of the code from this feature to grow under these CustomElementSomething and accompany classes. Hope this answers your question. -- morrita On Wed, Jan 30, 2013 at 4:52 PM, Maciej Stachowiak m...@apple.com wrote: On Jan 29, 2013, at 6:22 PM, Hajime Morrita morr...@chromium.org wrote: Hi folks, I'm going to implement Custom Elements standard behind ENABLE(CUSTOM_ELEMENTS) flag. https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html For reference: will the feature flag be comprehensive, or will parts of the implementation/scaffolding be outside the ifdef? - Maciej Here is the tracking bug for the feature: https://bugs.webkit.org/show_bug.cgi?id=99688 Note that Mozilla is also working on implementing this. https://bugzilla.mozilla.org/show_bug.cgi?id=783129 Let me know if you have any questions or comments. Bests, -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Feature announcement: Custom Elements
Hi folks, I'm going to implement Custom Elements standard behind ENABLE(CUSTOM_ELEMENTS) flag. https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html Here is the tracking bug for the feature: https://bugs.webkit.org/show_bug.cgi?id=99688 Note that Mozilla is also working on implementing this. https://bugzilla.mozilla.org/show_bug.cgi?id=783129 Let me know if you have any questions or comments. Bests, -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Implementing Complex webform Widgets using ShadowDom
Hi Hema, If you are talking about WebKit and HTML, it already does it for some of its built-in HTML elements. Some UI controls, which are modal and don't fit into the page layout, are implemented using native UI controls. These modal controls shouldn't constrained by WebKit rendering area like iframes. In such case, OS native controls are suited. File chooser is a perfect example of this. Some other controls like progress bars and spin buttons are implemented using Shadow DOM. They aren't modal and need to be parts of the page layout. The decision which of native-controls/shadow-dom should be used for implementing HTML form controls is case by case and in't that simple. You can see how input element is implemented. When you try to implement any new control for HTML, it would be good to file a bug and have further discussion there. See http://www.webkit.org/coding/adding-features.html If you are talking about Web-app or JS library development, webkit-dev isn't a place for that. Sites like stackoverflow.com will work well. There are also some good tutorials. For example: http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom/ Hope this helps. -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Prefix naming scheme for DOM-exposed functions
(sending from correct address)
Come late here. I basically support Darin's point.
Here is some addition:
As Maciej said, we don't need to do this for all API. We can do this by
opt-in basis, as an optimization.
Since we have [implementedAs] IDL attribute already, we can even start this
today once consensus on prefix naming is made (I'd vote for binding
prefix.)
On taking error check apart, another possible idea is to get more help from
our code generators.
For example, we could add API NameCheck C++ function which returns an
ExceptionCode, then we could let generated code call it appropriately.
// IDL will look like this:
[IfCheckFail=ReturnNull] readonly attribute Node firstChild;
// generated code will look like this.
ExceptionCode ec = impl-firstChildCheck();
if (ec)
return jsNull();
return toJS(impl-firstCihld());
// implementation could be
Node* ContainerNode::firstChild() const {
ASSERT(!firstChildCheck());
return m_firstChild;
}
I expect that there are only a few major patterns for handling and
reporting errors.
So we can also tell such patterns to the generator.
// Another IDL example:
[ExceptionIfNull=InvalidStateErorr] readonly attribute Node startContainer
getter raises(DOMException);
// generated code will be something like...
RefPtrNode return = impl-startContainer();
if (!return) {
throwException();
return jsNull();
}
return toJS(return);
This IDL annotations plus optional C++ helpers approach isn't as clean
(or simple) as uniform prefixing.
But it could result less hand-written C++ code and achieve same performance
benefit as original proposal.
Its opt-in nature will also help us try these ideas incrementally.
On the other hand, this could possibly result more complex, hard to
understand code backed by half-baked magic, if we do this badly.
I don't think this becomes that complex though.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Github vs. git.webkit.org
It looks github supports mirroring by pulling a repo from official location. http://stackoverflow.com/questions/11370239/creating-an-official-github-mirror So we might be able to rename the existing one and ask github to pull our git.webkit.org repository into github/WebKit/webkit. Apparently Apache takes that way: https://github.com/apache The mirroring icon indicates kind of official-ness. I don't know how long their mirroring delay is, though. On Sat, Dec 1, 2012 at 12:07 AM, Tor Arne Vestbø tor.arne.ves...@digia.comwrote: On 11/28/12 16:55 , Adam Barth wrote: My sense is that the WebKit community would prefer that the hashes in GitHub match the hashes in git.webkit.org so that folks can more easily move branches between the two. For my part, I've switched over to using GitHub exclusive of git.webkit.org, so the the difference in hashes aren't an issue for me, but I can understand why they'd be problematic for other people. Yepp, agreed. Let's switch it over. After the force-push, would you still be able to push updates automatically? If so, you can switch the hashes whenever is convenient for you. (It might be nice to announce the date/time on this list so that folks aren't taken by surprise.) The mirror is also pushed to http://gitorious.org/webkit/**webkithttp://gitorious.org/webkit/webkit, which I was planning to keep as is for now, so that would mean setting up an extra mirroring for the non-author-rewritten history :/ Also, the server I run this on has a somewhat uncertain future. With that in mind it's probably easier to just push directly from the same import that's pushed to git.webkit.org, and make the GitHub mirror an official mirror? tor arne __**_ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/**mailman/listinfo/webkit-devhttp://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is UseV8.cmake still used?
IIRC, Android (non-Chrome) uses V8. I'm not sure whether PLATFORM(CHROMIUM) is on there. On Sun, Nov 11, 2012 at 3:59 PM, Kentaro Hara hara...@chromium.org wrote: EFL and other ports used to have an option to build with V8, but it looks like the option is no longer supported. For example, UseV8.cmake is already out of sync with existing V8 binding files. - Would it be OK to remove UseV8.cmake? - Would it be OK to remove #if PLATFORM(CHROMIUM) from all V8 binding files? If anyone has a plan to support the option in the near future, I'll keep them as is. -- Kentaro Hara, Tokyo, Japan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] List of IRC nicknames pictures?
(From right address...) On Sun, Nov 4, 2012 at 8:14 PM, Ryosuke Niwa rn...@webkit.org wrote: On Sun, Nov 4, 2012 at 2:45 AM, Peter Beverloo pe...@chromium.org wrote: IRC nicknames are available in committers.py, as the third argument of the Contributor, Committer and Reviewer entries: http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/config/committers.py I am certainly aware of that. You can even ask sheriffbot with whois command. I'm not aware of any picture database. I guess we could include them on the WebKit Team wiki page, I don't think having people upload images to wiki is a scalable solution. How about ohloh? https://www.ohloh.net/p/WebKit/contributors shows gravatar.com pictures associated with commits. Propbably we could have an optional link to gravatar icon and some other informal data in committers.py then we can auto-generate pretty-looking alternative to http://trac.webkit.org/wiki/WebKit%20Team. Sounds like a good weekend project :-) but I'm not convinced the benefit would be worth the effort of adding that much images. If you use Gmail as your e-mail client, it'll somehow figure out these images anyway. I guess people don't mind even if I can't remember who they are? And no, Gmail isn't a solution for this either because very few people ever post things on webkit-dev, and many contributors don't use Gmail. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] On returning mutable pointers from const methods
We could have both const and non-const versions. For document(), we will certainly need both. I think these APIs can become less useful because the strict const-ness is yet to be deployed widely. We can apply the rule for fresh classes line new Web APIs since these rule worry little about older, less-const code. We'll need certain level of compromise for existing code. This means we cannot automate these check but it looks a reasonable starting point. -- morrita On Fri, Oct 26, 2012 at 12:53 PM, Elliott Sprehn espr...@chromium.orgwrote: This requires weird contortions in the DOM and Render tree and removes nice guarantees. For example Node.h has: TreeScope* treeScope() const; Document* document() const; Node* childNode(unsigned index) const; Returning a const Document* or Node* from childNode makes the DOM API's suddenly less useful, and marking them as non-const is confusing. These methods shouldn't be making mutations and the compiler should enforce that (or at least try to), and the const is also good documentation. On Thu, Oct 25, 2012 at 1:02 PM, Peter Kasting pkast...@google.com wrote: On Thu, Oct 25, 2012 at 3:48 AM, Andreas Kling kl...@webkit.org wrote: So, I propose that we allow only these two signature formats for raw pointers: - const Foo* foo() const; - Foo* foo(); ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Pre-proposal: Adding a Coverity instance for WebKIt
On Tue, Sep 18, 2012 at 8:46 AM, Eric Seidel e...@webkit.org wrote: On Mon, Sep 17, 2012 at 6:35 PM, Benjamin Poulain benja...@webkit.org wrote: On Mon, Sep 17, 2012 at 4:11 PM, James Hawkins jhawk...@chromium.org wrote: A few details: * Google will front the cost of the license (non-zero...very far from zero) and the infrastructure. * I'd leave it up to the WebKit leadership to decide who has access (most likely limited to WebKit committers for security purposes). The biggest rationale is to provide a strong defect signal for the entire WebKit community, which would directly impact the success of all WebKit-based projects. Coverity has provided free licenses for unsponsored (by larger corporations anyway) open-source projects; this has resulted in significant improvements [2] to the code bases of these projects, one of which I was directly involved with years ago (Wine). I am a little skeptical of Coverity because of bad patches that originated for its report (sometimes even discussed on webkit-dev). I think we should keep in mind the tool also make many mistakes and we should not blindly follows it. Could this be integrated with the EWS like a kind of advanced style check? I think this is a great idea, and would be trivial if coverity could be convinced to run on a diff file, or if we could wrap it in a script to only report errors on the changed lines. Either sounds very And/Or are we going to allow inline annotations? The practice Coverity suggested is to adding such annotations. http://scan.coverity.com/best-practice.html I personally think it's worth having inline annotations because it can also help human code readers, so I'm curious what other folks think about that. doable. The EWS infrastructure is already in place once such a script exists. Reporting possible improvements before patches lands would be more useful than a separate bot. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Multiple inheritance in the DOM
If the only problem is to determine the type of JS wrappers, is it possible to make wrapSlow() a virtual method of some base class, instead of static functions? It need a tweak on the code generator. Also, it might need to avoid name conflicts by suffixing like wrapSlowForNode(), wrapSlowForRegion() etc. This approach would make wrapSlow() a variation of QueryInterface(). But considering that the functionality is limited and hard to abuse, it might be better than having DOMInterface. On Thu, Jul 26, 2012 at 9:53 AM, Alan Stearns stea...@adobe.com wrote: On 7/25/12 5:37 PM, Sam Weinig s...@webkit.org wrote: On Jul 25, 2012, at 5:13 PM, Alan Stearns stea...@adobe.com wrote: On 7/25/12 4:49 PM, Kentaro Hara hara...@chromium.org wrote: A) Should we push back on the folks writing the CSS Regions specification to avoid using multiple inheritance? As far as I know, this is the only instance of multiple inheritance in the platform. Historically, EventTarget used multiple inheritance, but that's been fixed in DOM4 [4]. If it is possible to avoid the multiple inheritance, that would be best. From the WebIDL side, it's not strictly multiple inheritance. It's merely a supplemental interface that more than one object can implement. None of the members of the Region interface can clash with any of the members of the object that implements it. Right now Elements can become CSS Regions, but in the future other objects will be able to become CSS Regions. As far as I know, the correct way to specify this kind of relation is with WebIDL supplemental interfaces. I'd rather figure out the correct way to add this WebIDL functionality to WebKit now, than put something else into the spec and WebKit that we'll have to change later. Thanks, Alan What other objects do you envision implementing CSSRegion? With the spec written the way it is now, I see no reason to make anything virtual, or even have a Region class. Just implement it in Element. If need to pull things out for code reuse purposes, we can do that when it comes to that, but right now, there doesn't seem to be a need to complicate things. -Sam I have an upcoming proposal for a CSSPseudoElement object. You can make a pseudo-element like ::before or ::after into a CSS Region right now in WebKit. All that's lacking is a way to access those pseudo-elements from script. Thanks, Alan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Using commit-queue doesn't mean you can use build failures
(from the right address...) Hi, I don't think it is a reasonable expectation especially for non-chromium developers. It is possible for a change to break chromium-linux, chromium-win or chromium-mac, that means developers needs to have Linux, Mac and Windows machines to ensure the successful build since there is no EWS for these configurations. More reasonable baseline would be getting all EWS builds green and/or watching the tree until landed patch goes green. And in my understanding, these are in fact our current norm. Regards, -- morrita On Thu, Jul 19, 2012 at 3:59 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi all, Using commit-queue doesn't pardon a committer from causing build failures. Notice that the commit queue only builds runs tests on Chromium Linux port. Thus, any build failure that doesn't manifest itself on Chromium Linux port — namely any JSC-specific or Windows/Mac specific build failures — won't be caught. The current policy specifically says the committer is responsible for making sure his or her patch builds passes tests: http://www.webkit.org/coding/contributing.html So please make sure your patch at least builds if you're landing a patch via commit queue. Best, Ryosuke Niwa Software Engineer Google Inc. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] C++ unit tests for WebKit?
(Resending from the right address) FYI, Chromium port has some unit-like tests: http://trac.webkit.org/browser/trunk/Source/WebKit/chromium/tests Apparently it is not community's responsibility to maintain these. But it might be useful for developing some low-level standalone/low-level stuff like collections and utilities if you are developing on Chromium port. My feeling is that the lack of unit test is mixture of philosophical decisions and technical limitations. As Adam mentioned, Layout Tests for Web Platform features fit former, and untested low level stuff fits later. If we have some low-level/primitive component for building larger web platform features, such primitives are worth unit-testing IMHO. And TestWebKitAPI (or cr-port test in some case) is good place for them. On Thu, Jul 12, 2012 at 8:48 AM, Adam Barth aba...@webkit.org wrote: On Wed, Jul 11, 2012 at 4:31 PM, Hans Muller hmul...@adobe.com wrote: Thanks for the thoughtful reply. It was exactly the community's conventions and customs that I was trying to get a handle on. Not to put too fine a point on it, but I assume that adding unit tests to TestWebKitAPI or writing tests that depend on APIs defined in Internals.idl wouldn't be customary or conventional? As the name implies, TestWebKitAPI is mostly about testing the WebKit API (meaning the API that WebKit exposes to folks who use it as a library). Your feature doesn't seem to involve any WebKit API, so I would steer clear of TestWebKitAPI. We're still feeling out when it's appropriate to test something via Internals. One good use of Internals is to set a WebCore::Setting directly rather than having to create API for N different ports. There's a risk that Internals will become a dumping group for random things, and this is something we try to look out for when reviewing changes to Internals.idl. I'd been thinking about doing the latter (Internals.idl), just because it would enable testing some low level classes before everything we're working on had been integrated top to bottom. Doing so could just be a private temporary change, since eventually it will be possible to exercise the code via public APIs. Obviously, you should feel free to do whatever is convenient in your own private branch. For development on trunk, I would encourage you to try to get a basic version of your feature working end-to-end (so that it's testable via the web platform) and then to elaborate it incrementally. That's not always possible, but it tends to be a good approach for generating test coverage. I'm happy to discuss this topic further in #webkit if that would be helpful to you. Adam From: Adam Barth aba...@webkit.org To: Hans Muller hmul...@adobe.com Cc: Benjamin Poulain benja...@webkit.org, Konrad Piascik kpias...@rim.com, webkit-dev webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] C++ unit tests for WebKit? Generally speaking, WebKit's testing philosophy is to test at API boundaries, typically either a given port's WebKit API or the web platform API. The benefit of that approach is that it makes it easier for us to refactor the internals of WebCore without being constrained by fragile tests---only by API commitments. In the case of CSS Exclusions, it's likely valuable to think about how you can test the feature via the web platform. Developing a rich set of tests that use web platform APIs has a number of follow-on benefits that WebCore-internal testing doesn't, such as the ability to run the tests in other browsers and to contribute them to the W3C as part of the standards process. Of course, this sort of one-size-fits-all testing strategy works well in come cases in less well in others. I understand that other projects have different testing strategies that have worked well for them, but I would encourage you to try our the community's conventions and customs for a while to get a feel for which ones work well and which ones ought to be improved. Adam On Wed, Jul 11, 2012 at 3:44 PM, Hans Muller hmul...@adobe.com wrote: It looks like Tools/TestWebKitAPI/Tests/WebCore just contains one small KURL test. I could certainly add more for the Exclusions shape classes, but I got that feeling that maybe you get about being the first to take a table at an empty restaurant. Perhaps it's just that most of the C++ classes in WebCore are too interdependent to merit unit testing? - Hans On 7/11/12 2:26 PM, Benjamin Poulain benja...@webkit.org wrote: On Wed, Jul 11, 2012 at 2:23 PM, Hans Muller hmul...@adobe.com wrote: Have the merits of C++ unit tests been debated before? I noticed that a bug representing as much has been around since 2008 (https://bugs.webkit.org/show_bug.cgi?id=21010). The last comment (2009) concludes with: I'd be interested to hear other's thoughts. Personally, I'd like to be able to include unit tests with worthy C++ classes, however I would also like to hear other's
Re: [webkit-dev] Can protocol handler be moved to the modules ?
This change looks reasonable for me. I hope the client interface to be extracted from ChromeClient to its own. ChromeClient is like a zoo of ifdefs, which modularization effort has aimed to improve. (I don't think we need to split the implementations of ChromeClient: they can implement both interfaces) On Tue, Jul 10, 2012 at 2:26 PM, Gyuyoung Kim gyuyoung@samsung.com wrote: Hello folks, I wonder whether protocol handler is able to be moved to the modules. I was told that protocol handler belonges Current Non-Modules Using Module-Related Techniques for Loose Coupling == Current Non-Modules Using Module-Related Techniques for Loose Coupling == devicemotion deviceoritentation fileapi html notifications protocolhandler speechinput svg webgl websql workers xml http://lists.webkit.org/pipermail/webkit-dev/2012-February/019628.html However, it seems to me protocol handler is now self-contained except for an interface which supports port implementation. In intents case, it also has similar interface in FrameLoaderClient.h. Is there any reason that protocol handler can't be moved to the modules ? I filed a bug for this and submitted a patch. https://bugs.webkit.org/show_bug.cgi?id=90766 Cheers, Gyuyoung. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Reg.use of WTF_CHANGES in FastMalloc.cpp...
Hi, The code was brought from a third party library and WebKit (WTF) needs some changes to the original code. It looks such changes are marked by WTF_CHANGES. For example, WTF shouldn't depend on gflags, which is disabled by the WTF_CHANGES guard. -- morrita On Thu, Apr 12, 2012 at 6:01 PM, Arunprasad Rajkumar ararunpra...@gmail.com wrote: I don't understand the use of define WTF_CHANGES in FastMalloc.cpp TCSystemAlloc.cpp. Any body help me to understand that? Thanks in advance. -- Arunprasad Rajkumar ___ 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] Documentation for WTF/JSC exports?
On Thu, Mar 22, 2012 at 10:38 AM, Eric Seidel e...@webkit.org wrote: Thank you. Mark Rowe was kind enough to resolve https://bugs.webkit.org/show_bug.cgi?id=81838#c8 in http://trac.webkit.org/changeset/111634. I've found that some of the Weak External Symbol errors from http://pastebin.com/dVjV8UiR can be resolved by marking the functions in question as inline, but that doesn't seem like the right fix. Some others like: ERROR: symbol double WTF::strtod(WTF::AllowTrailingJunkTag)0, (WTF::AllowTrailingSpacesTag)0(char const*, char**) You may need GCC_SYMBOLS_PRIVATE_EXTERN = YES; on WTF.xcconfig. JavaScriptCore.xcconfig has it. Are for functions which are not even in headers: http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/wtf/dtoa.cpp#L651 So it's unclear what's causing those. Thank you for your attempts at documentation. Perhaps that will make clear how these exports are supposed to work. :) -eric On Wed, Mar 21, 2012 at 6:21 PM, Hajime Morrita morr...@google.com wrote: I'll write a draft so that ports' expert can fill missing pieces. -- morrita On Thu, Mar 22, 2012 at 9:49 AM, Eric Seidel e...@webkit.org wrote: Do we have any documentation for how the current symbol export system for WTF/JSC is supposed to work? I'm hitting errors when trying to move WTF files to their own libwtf.a, such as: https://bugs.webkit.org/show_bug.cgi?id=81838 and http://pastebin.com/dVjV8UiR But looking at http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/wtf/ExportMacros.h It appears most of those macros are never used! (Like WTF_EXPORT_CLASS, for example.) So when trying to resolve errors such as: https://bugs.webkit.org/show_bug.cgi?id=81838#c8 The path is unclear. Perhaps there is a wiki somewhere on how this system is supposed to work? -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Documentation for WTF/JSC exports?
I'll write a draft so that ports' expert can fill missing pieces. -- morrita On Thu, Mar 22, 2012 at 9:49 AM, Eric Seidel e...@webkit.org wrote: Do we have any documentation for how the current symbol export system for WTF/JSC is supposed to work? I'm hitting errors when trying to move WTF files to their own libwtf.a, such as: https://bugs.webkit.org/show_bug.cgi?id=81838 and http://pastebin.com/dVjV8UiR But looking at http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/wtf/ExportMacros.h It appears most of those macros are never used! (Like WTF_EXPORT_CLASS, for example.) So when trying to resolve errors such as: https://bugs.webkit.org/show_bug.cgi?id=81838#c8 The path is unclear. Perhaps there is a wiki somewhere on how this system is supposed to work? -eric ___ 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] Documentation for WTF/JSC exports?
Done: https://trac.webkit.org/wiki/ExportingSymbols It doesn't looks this helps your WTF move though. On Thu, Mar 22, 2012 at 10:38 AM, Eric Seidel e...@webkit.org wrote: Thank you. Mark Rowe was kind enough to resolve https://bugs.webkit.org/show_bug.cgi?id=81838#c8 in http://trac.webkit.org/changeset/111634. I've found that some of the Weak External Symbol errors from http://pastebin.com/dVjV8UiR can be resolved by marking the functions in question as inline, but that doesn't seem like the right fix. Some others like: ERROR: symbol double WTF::strtod(WTF::AllowTrailingJunkTag)0, (WTF::AllowTrailingSpacesTag)0(char const*, char**) Are for functions which are not even in headers: http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/wtf/dtoa.cpp#L651 So it's unclear what's causing those. Thank you for your attempts at documentation. Perhaps that will make clear how these exports are supposed to work. :) -eric On Wed, Mar 21, 2012 at 6:21 PM, Hajime Morrita morr...@google.com wrote: I'll write a draft so that ports' expert can fill missing pieces. -- morrita On Thu, Mar 22, 2012 at 9:49 AM, Eric Seidel e...@webkit.org wrote: Do we have any documentation for how the current symbol export system for WTF/JSC is supposed to work? I'm hitting errors when trying to move WTF files to their own libwtf.a, such as: https://bugs.webkit.org/show_bug.cgi?id=81838 and http://pastebin.com/dVjV8UiR But looking at http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/wtf/ExportMacros.h It appears most of those macros are never used! (Like WTF_EXPORT_CLASS, for example.) So when trying to resolve errors such as: https://bugs.webkit.org/show_bug.cgi?id=81838#c8 The path is unclear. Perhaps there is a wiki somewhere on how this system is supposed to work? -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Using GitHub to Contribute to WebKit (Experimental)
On Fri, Mar 16, 2012 at 6:50 PM, Konstantin Tokarev annu...@yandex.ru wrote: 16.03.2012, 04:41, Adam Barth aba...@webkit.org: Hi webkit-dev, After reading last week's discussion about switching the project to git, I wondered if it would be possible to get some of the benefits of git-style development without forcing everyone to switch to git. One of the benefits of git-style development is the ability to review a series of patches at once. GitHub has some nice tools to reviewing pull requests, so I wrote up a short wiki page describing how someone might use GitHub to contribute to WebKit: https://trac.webkit.org/wiki/UsingGitHub I'm not sure we'll want to switch the whole project over to GitHub any time soon, but it might be something that folks who like git might want to experiment with. Don't you consider using Gerrit[1]? It's more effective review tool for git. The hardest part would be finishing the setup and making it up and running. Unlike the build slaves which can go down and lost sometimes, The code review records need to be more permanent since people want to read the conversation and see how decisions were made. That's being said, I personally agree that Gerrit can be a great choice. Starting from an experiment like Adam is suggesting to GitHub won't hurt, if someone does setup the server. -- morrita [1] http://code.google.com/p/gerrit/ -- Regards, Konstantin ___ 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] exporting symbols for building .so/.dll's
(From the right address again...)
On Sun, Mar 11, 2012 at 9:34 AM, Alp Toker a...@nuanti.com wrote:
On 09/03/2012 03:52, Ami Fischman wrote:
Hi webkittens,
The over-all question: how should webkit libraries declare which symbols
they export?
The trigger for the question: as described in bug 80062, the chromium
shared-library-based build links test code into the (non-test) libwebkit.so
target, which is terrible.
The details:
I took a crack at fixing the above bug (see patch in the bug) by pulling the
test files out of the non-test build target, and sprinkling various
{WTF,WEBKIT}_EXPORT{,DATA} macros around declarations that need them (as
discovered by build-time and run-time failures). This style of export
declaration is what the webkit codebase does in various places
(WTF, Platform, WebCore, and WebKit, AFAICT), and incidentally also what
the chromium project uses for its sub-components.
But I'm told other ports use different mechanisms such as .exp.in files for
apple/mac (and maybe others for other ports? IDK).
Is there consensus on the list for what the Right Thing To Do(tm) is?
ISTM my options are:
1) Add EXPORT declarations as in the patch on the bug.
2) Drop the patch from the bug and replace it with chromium-specific
.exp.in-style files, one per layer from which I need to export (WebCore,
WTF, WebKit). And build the build-time machinery to use them. I don't
really know what's involved here and would appreciate any pointers/hints
people had if this is the way to go.
3) Something else (preferably unifying other ports' approaches).
Help me webkit-dev, you're my only hope (for consensus).
I think the export macros would only ever have made sense if they were put
there explicitly to guide refactoring of the classes into a library /
interface structure. And this isn't the case.
At present I don't see an active effort towards that, or much interest in
defining the public interfaces in each 'module' more strictly. They're
intentionally fluid.
Having said that, the macros are /vaguely/ useful to see what could be made
private or hidden in future shuffling of the code in wtf, for example, but
that's about it.
The very fact that the export macros have to be updated with a tool every
time a library higher in the link chain uses or doesn't use a public entry
point, and that the set of imported functions or variables varies between
ports indicates that this is not going to have wide adoption.
This is same for port specific export lists.
To keep the tree green, the community needs to maintain the list
regardless it is externalized from or embedded in the source.
And maintaining the set of export lists has larger pain than
maintaining a macro-based annotation.
Thus keeping it isolated won't help us much.
, and that the set of imported functions or variables varies between
ports indicates that this is not going to have wide adoption.
As mrobinson@ mentioned, there is a set of the least common denominator.
My guess is that the number of symbols which is different between
ports will be less than a half of the total.
If we accept such overhead, it could be a preferable option.
If we follow this to the logical conclusion, no unification of granular
export lists is realistic with the current WebKit porting layer. If the
strategy were adapted to define exported functionality at class granularity,
it might just be feasible, but again that is a contract that is begging to
be broken, and besides, most toolchains lack export-by-class so it's a moot
point.
At least recent gcc+ld and link.exe support such a class level annotation.
For GNU chain, the lack of support seems like an old story:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9283
My feeling is that the macro annotation is never for declaring a public API.
It's just a pretty convenient replacement of the port specific export
lists, with small overhead from possible unwanted exports.
It's different from WebKit API which each port is providing.
There is no commitment for compatibility, as the _PRIVATE suffix indicates.
To clarify: I think that there should be WEBCORE_EXPORT_PRIVATE but no
WEBCORE_EXORT.
This is unlike JSC, which has both JS_EXPORT and JS_EXPORT_PRIVATE.
(I prefer some shorter name btw... but it's a different topic.)
So the ultimate course of action is then to revert the macros and leave
everyone to do what they think best in terms of export lists, then tying
together those solutions where there's overlap.
So, as I wrote above, this course seems based on a wrong assumption:
The annotation as a public API.
No, it won't. It could be fluid. it would be just an internal tool
which only WebKit port implementations can rely on.
Does this make sense?
--
morrita
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] exporting symbols for building .so/.dll's
I found some confusion here. There are two kinds of symbols which need to be exported from WebCore. - A. Symbols from WebCore to WebKit(API). This is basically what WebCore.exp.in covers. - B. Symbols from WebCore to Application. In principle, there should be no such symbols. But in reality there is some. Symbols for Internals objects follow this pattern. Note that the number of B is significantly smaller than one of A. It looks Alp's main concern is about B. But I implicitly assumed A. Currently A matters only for Mac WK1 port (Webcore.exp.in). Some other ports including GTK, WebKit2 needs B. (symbols.fiter, WebKit_Cairo.def, etc.) Mac WK1 also needs B. But it's in the same WebCore.exp.in list. For A, it should be marked as WEBCORE_EXPORT_PRIVATE if we use inline annotations. For B, it should use WEBCORE_EXPORT. For A, I think it's infeasible to replace it with inline annotations because the .exp list and inline annotations are mutually exclusive. So we need to make it happen at once. But it's not a simple job. I think we need some incremental transition plan. It might be someting like what Alp mentioned, that is, to use nm or whatever to automate exp list generation, etc. For B, it's relatively easy to turn the macro on because its number is small. The symbols.filter file shows about 100 symbols, which would be manually convertible. What's tricky is that Chromium component build wants yet another kind of symbols: The symbols is for unit testing. Let me call it C otpion here. C is different from either A or B. It touches deep WebCore internals which people don't need to export unless they write unit tests, that is current WebKit situation. So, - Some ports need A+B (ex. Mac WK1 Port) - Some ports need B (ex. GTK, Windows) - Some ports need B+C (Chromium) And my feeling is that Chromium is OK to have A if it's available. Having that said, here is my proposal: - Let's introduce WEBCORE_EXPORT for B. Chromium will use this, GTK and Windows also could use. (For GTK, I expect this to have same definition as WEBKIT_API.) - Let's NOT introduce WEBCORE_EXPORT_PRIVATE for now because it would be useless unless we don't get rid of WebCore.exp.in, which won't easy. - Let's introduce WEBCORE_EXPORT_TEST for C. Chromium will enable and use this for now. - If WEBCORE_EXPORT and WEBCORE_EXPORT_TEST conflicts, WEBCORE_EXPORT win. - If WEBCORE_EXPORT_PRIVATE and WEBCORE_EXPORT_TEST conflicts, WEBCORE_EXPORT_TEST win. - If WEBCORE_EXPORT and WEBCORE_EXPORT_PRIVATE conflicts (in the future), WEBCORE_EXPORT win. Then we can start from adding C for Chromium, which doesn't have any export list before. Chromium will also need B. Having B would be good news also for GTK and Windows port because these no longer need to touch their symbols file for each time the Internals object needs one. I'm happy to help this to happen. (... and I'd like to ask Ami to help ;-)) What do you think? -- morrita On Mon, Mar 12, 2012 at 9:16 AM, Ami Fischman fisch...@chromium.org wrote: Responding to several emails below. Adam wrote: I'm not sure I understand your proposal fully. Specifically, how would these macros work for, say, the Chromium, Apple-Mac, and Apple-Win ports, which export overlapping, but not identical, sets of symbols? I do not have a proposal to unify the export story across ports. My proposal (such as it is) is limited to removing test code from the non-test webkit target (see the patch on the bug). AFAICT from this thread there is no consensus on unifying options that doesn't have as its first step achieve consensus on the complete public API of each library layer, and I didn't get the sense that this is a realistic goal, at least for me at my current level of engagement. Adam also wrote: Relatedly, do you plan to replace http://trac.webkit.org/browser/trunk/Source/WebCore/WebCore.exp.in with EXPORT macros, or will we have both macros and an export list for an extended period of time? The latter. To put things in perspective, WebCore.exp.in is over 2000 lines long; my patch macro-annotates ~40 classes in WebCore (which is a far cry from, say, doubling the pain of WebCore.exp.in). I'm also emboldened in this respect by the coexistence of WEBKIT_EXPORT and Source/WebKit/mac/WebKit.exp. Alp wrote: Doesn't the list of exports change massively based on the level of inlining and compiler optimisation? Which configuration is the target to aim for, and which compiler vendor? Doesn't the list also change between releases of the same compiler? AFAICT the answers to your questions are all no, for the limited scope of my change (some indication of this is that I only tested my patch on chromium/linux, but it's now green on all EWS bots after only needing to add #include's to get the definition of the export macro, not due to having to add extra annotations for some ports). As with the existing JSC_EXPORT and WEBKIT_EXPORT macros, the new
Re: [webkit-dev] exporting symbols for building .so/.dll's
(From the right address...)
Hi Ami,
I don't think there is a consensus about that. Here is my
understanding of the current status of the export symbol management:
At first, each port has different way to split libraries. For example,
- A) Mac port (WebKit1) splits WebKit into three frameworks: WebCore,
JavaScriptCore and WebKit.
(The last one is for Objective-C API which wraps WebCore.)
- B) Some others split it into JavaScriptCore and WebCore+WebKit.
- C) Chromium chooses yet another variation: making a single library
for whole WebKit.
This difference is one of the reasons why the way to export symbols is
different among ports.
For ports on approach C, it doesn't matter which WebCore/JSC API is
used from WebKit API layer because they are built in the same library.
For ports on approach B, only the symbols exported from JSC matter.
The dependency from WebKit API to WebCore doesn't.
For ports on approach A, symbols exported both from JSC and WebCore
matter because these two have their own libraries. APIs of these
libraries should be exported to be used by WebKit API library.
Also, there are port specific WebKit APIs (like WebFrame and WebString
of Chromium.) which have their own ways to export symbols. But in
general, people other than the port maintainers don't need to care
about that because there are few chances to change such APIs.
---
I'd try to clarify some more detail:
For JSC API, which A and B folks care about, there are two ways to
export it.
- For Windows port, there is JavaScriptCore.def.
- For Mac (and WX?) port, there are macro-based annotations like
JS_EXPORT, WTF_EXPORT_PRIVATE.
I'm in the way to eliminate JavaScriptCore.def by replacing it with
these annotations, but the migration isn't finished yet.
(http://wkb.ug/76257)
For WebCore API, we only need to care about WebCore.exp.in because Mac
port is the only one which follows A pattern. (I remember Windows
port used to use this pattern. But it looks no longer the case. Maybe
they changed the way when they switched to WebKit2. But my memory
might be just wrong...)
---
Having that long said, back to the original question:
Is there consensus on the list for what the Right Thing To Do(tm) is?
ISTM my options are:
1) Add EXPORT declarations as in the patch on the bug.
2) Drop the patch from the bug and replace it with chromium-specific
.exp.in-style files, one per layer from which I need to export (WebCore,
WTF, WebKit). And build the build-time machinery to use them. I don't
really know what's involved here and would appreciate any pointers/hints
people had if this is the way to go.
3) Something else (preferably unifying other ports' approaches).
- If the API is under JavaScriptCore/ (or WTF/), I'd recommend to use
JS_EXPORT and WTF_EXPORT_PRIVATE because we are under transition to
this path.
- If the API is under WebKit/chromium/, we can just use WEBKIT_EXPORT as before.
- If the API is under WebCore/, there is no consensus except we
already have WebCore.exp.in.
My personal preference is to introduce WebCore version of export
macros like WK_EXPORT_PRIVATE. In this way, we could use it to get rid
of WebCore.exp.in in the future.
Another possibility is to ride existing WebCore.exp.in somehow. Yet
another approach could be just giving up to have the unit test as a
separate binary and build it into the library for non-prod
configuration. The last one seems exactly what you are trying to avoid
though... One clear thing is that maintaining yet another exp file
will be bad news for almost everyone ;-)
Anyway, I'd like to hear thoughts from other folks.
Bests,
--
morrita
___
webkit-dev mailing list
On Fri, Mar 9, 2012 at 12:52 PM, Ami Fischman fisch...@chromium.org wrote:
Hi webkittens,
The over-all question: how should webkit libraries declare which symbols
they export?
The trigger for the question: as described in bug 80062, the chromium
shared-library-based build links test code into the (non-test) libwebkit.so
target, which is terrible.
The details:
I took a crack at fixing the above bug (see patch in the bug) by pulling the
test files out of the non-test build target, and sprinkling various
{WTF,WEBKIT}_EXPORT{,DATA} macros around declarations that need them (as
discovered by build-time and run-time failures). This style of export
declaration is what the webkit codebase does in various places
(WTF, Platform, WebCore, and WebKit, AFAICT), and incidentally also what
the chromium project uses for its sub-components.
But I'm told other ports use different mechanisms such as .exp.in files for
apple/mac (and maybe others for other ports? IDK).
Is there consensus on the list for what the Right Thing To Do(tm) is?
ISTM my options are:
1) Add EXPORT declarations as in the patch on the bug.
2) Drop the patch from the bug and replace it with chromium-specific
.exp.in-style files, one per layer from which I need to export (WebCore,
WTF, WebKit). And
Re: [webkit-dev] Adding -webkit-image-set CSS function
(Resending from the right address...) Hi Beth, Thanks for letting us know about this! The feature sounds gerat for anyone trying to make their pages more responsive. Are you going to add any compilation flags? Also, if there is a Bugzilla entry to track this, I'd like to know that. When announcing new feature, it would be appreciated if you mention these two points: http://trac.webkit.org/wiki/AddingFeatures Thanks, -- morrita On Fri, Mar 2, 2012 at 9:56 AM, Hajime Morrita morr...@google.com wrote: Hi Beth, Thanks for letting us know about this! The feature sounds gerat for anyone trying to make their pages more responsive. Are you going to add any compilation flags? Also, if there is a Bugzilla entry to track this, I'd like to know that. When announcing new feature, it would be appreciated if you mention these two points: http://trac.webkit.org/wiki/AddingFeatures Thanks, -- morrita On Fri, Mar 2, 2012 at 8:06 AM, Beth Dakin bda...@apple.com wrote: Hi all! Ted O'Connor recently proposed a new CSS function for the Images module to the CSS working group called image-set. The idea behind the feature is to allow authors to provide multiple variants of the same image at differing resolutions, and to allow the User Agent to choose the resource that is most appropriate at the time. We think this will be a great way to allow authors to specify high resolution resources for iPhone's retina display, and we imagine User Agents being able to choose different resolution resources when content is scaled or zoomed. There is some consensus on the list that a feature like this would be a good addition to CSS Images Level 4. Discussion is still ongoing about the exact syntax of the property, but we'd like to add an experimental implementation to WebKit; after all, such implementations often help guide features like this along. -Beth ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] build-webkit --maximal?
Hi Ashod, On Sat, Feb 25, 2012 at 5:38 PM, Ashod Nakashian ashodnakash...@yahoo.com wrote: Webkit-dev, We have --minimal to disable all optional features, but what about enabling everything? The use-case I have in mind is build sanity checking, where one might need to make sure no change broke code under a feature flag. Or may be that's something done by the build server or some other way I'm ignorant of? For some features, each port needs to provide its port-dependent part to make them work. And filling such gaps isn't a trivial work. I guess Mac port plus Chromium port provide pretty good coverage though. If you have a Mac-based box, you can build both on the same machine. You can build-webkit for building Mac port and build-webkit --chromium followed by update-webkit-chromium for building Chromium port. Also, a large part of build breakages comes from port specific bits which need certain setup to build. So hypothetical --maximum flag won't rescue anyway. That's why we have EWS bots on the Bugzilla. http://markmail.org/thread/hn5c2lqel5yvgslm Bests, -- morrita for Apple If not, I'm suggesting adding such a flag (perhaps called something else) that may be used to enable all flags (valid on the given platform). -Ash ___ 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] Should we move methods from layoutTestController/etc... to internals?
On Wed, Feb 22, 2012 at 10:48 AM, Maciej Stachowiak m...@apple.com wrote: On Feb 21, 2012, at 5:40 PM, Hajime Morrita wrote: Hi, Thanks for starting this discussion! To summarize, there is a rough consensus which is like: * A. LayoutTestController (LTC) is for control test harness. dumpAsText() and waitUntilDone() is great example of this. * B. EventSender and some other stuff are for emulating external events like user input. keyDown() is good example. * C. Internals is for inspecting WebCore internal state which isn't available from WebKit API. Inspecting spellcheck markers is one typical example. But I found that there are some test-specific APIs which don't fit well in any of listed categories: * D. Changing Settings and RuntimeFeatures values. Inspecting flags in these objects is a good fit for Internals. But how about changing these values? I feel that it's no longer inspecting. On the other hand, we know that adding new WebKit and LTC API for each these flags is certainly tedious work especially the flag is just for disabling/enabling half-baked features. Currently we have several flag setters on Internals object but I worry a bit this as a start of abusing Internals. My feeling is that it's OK to use Internals family assuming that getting/setting flags are trivial enough so that we don't need to worry about unexpected side-effects. We already have InternalsSettings for this purpose. * E. Invoking some WebCore API which implements portable WebKit API. This is one step forward from D. There are some WebKit APIs which just call corresponding WebCore methods. A good example of WebCore side is WebCore::Page::setDeviceScaleFactor(): There is a discussion to whether we should add a wrapper API for this to Internals: http://wkb.ug/74014. This API is less trivial than changing settings since this isn't just a parameter setting but has a side effect. On the other hand, some API like this has no platform-specific part. WebKit API just calls this. It could be felt as a waste of abstraction if we add LTC API for that - it will just stack a few more call frames. I think we could cover this usecase by some Internals-like object. But it should never be Internals itself and ideally a wrapper of WebCore object. For example, we could have something like PageWrapper for WebCore::Page which could be implemented in the same way as Internals. Or, we could employ the controller-client pattern to have IDL generated class in shared WebCoreTestSupport and let each DRT to implement the client. This could eliminate the need for hand-written bindings even though we need to have some per-port stuff. * F. Purely for testing, but portable mechanism. Mocking some clients are primary example of this. Mock objects are rarely platform specific and implementing it in each platform is nothing more than coding practice IMHO. I understand that there are some controversy around mock itself. But we have some features which are hard to test in automated manner without mock. For this, we could do same as E. I think LTC isn't good place for neither D, E or F. But Internals also isn't. What do you think? For D, E and F, I think the methods should be split up into object by purpose rather than by how they'd be implemented. I agree that these methods shouldn't be piled onto a single LayoutTestController object. That's right. One concern I have about settings: poking through the WebKit API layer to set settings directly in WebCore may not necessarily work as expected in all WebKit ports, or at least it will violate implementation invariants. For example, in WebKit2 (currently using the WebKitTestRunner tool which is separate from DumpRenderTree at present), both the WebProcess and the UI process need to know about settings. This makes me think that settings (at least ones surfaced at the API level) should actually go through the WebKit API rather than poking directly into WebCore via the internals object. Good point. I wasn't aware of this. In my understanding, the problem here is that these states can be out-of-sync. Considering so, we can move a part of Settings parameters to RuntimeFeatures, which doesn't need to be updated dynamically. I guess there is a certain numer of flags in Settings which are't changed from the default outside the test. Thanks for pointing this out. Bests, -- morrita Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Should we move methods from layoutTestController/etc... to internals?
Hi, Thanks for starting this discussion! To summarize, there is a rough consensus which is like: * A. LayoutTestController (LTC) is for control test harness. dumpAsText() and waitUntilDone() is great example of this. * B. EventSender and some other stuff are for emulating external events like user input. keyDown() is good example. * C. Internals is for inspecting WebCore internal state which isn't available from WebKit API. Inspecting spellcheck markers is one typical example. But I found that there are some test-specific APIs which don't fit well in any of listed categories: * D. Changing Settings and RuntimeFeatures values. Inspecting flags in these objects is a good fit for Internals. But how about changing these values? I feel that it's no longer inspecting. On the other hand, we know that adding new WebKit and LTC API for each these flags is certainly tedious work especially the flag is just for disabling/enabling half-baked features. Currently we have several flag setters on Internals object but I worry a bit this as a start of abusing Internals. My feeling is that it's OK to use Internals family assuming that getting/setting flags are trivial enough so that we don't need to worry about unexpected side-effects. We already have InternalsSettings for this purpose. * E. Invoking some WebCore API which implements portable WebKit API. This is one step forward from D. There are some WebKit APIs which just call corresponding WebCore methods. A good example of WebCore side is WebCore::Page::setDeviceScaleFactor(): There is a discussion to whether we should add a wrapper API for this to Internals: http://wkb.ug/74014. This API is less trivial than changing settings since this isn't just a parameter setting but has a side effect. On the other hand, some API like this has no platform-specific part. WebKit API just calls this. It could be felt as a waste of abstraction if we add LTC API for that - it will just stack a few more call frames. I think we could cover this usecase by some Internals-like object. But it should never be Internals itself and ideally a wrapper of WebCore object. For example, we could have something like PageWrapper for WebCore::Page which could be implemented in the same way as Internals. Or, we could employ the controller-client pattern to have IDL generated class in shared WebCoreTestSupport and let each DRT to implement the client. This could eliminate the need for hand-written bindings even though we need to have some per-port stuff. * F. Purely for testing, but portable mechanism. Mocking some clients are primary example of this. Mock objects are rarely platform specific and implementing it in each platform is nothing more than coding practice IMHO. I understand that there are some controversy around mock itself. But we have some features which are hard to test in automated manner without mock. For this, we could do same as E. I think LTC isn't good place for neither D, E or F. But Internals also isn't. What do you think? -- morrita On Wed, Feb 22, 2012 at 8:43 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Tue, Feb 21, 2012 at 3:39 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Feb 21, 2012 at 3:14 PM, Maciej Stachowiak m...@apple.com wrote: On Feb 21, 2012, at 1:21 PM, Ryosuke Niwa wrote: I'd prefer getting rid of the entire interface when possible. We're obviously removing layoutTestController, textInputController, etc... at the moment though. I think it's helpful to organize the methods by functional area instead of dumping them all onto one giant interface. layoutTestController for example has far too many methods, in my opinion. We would not design a public API where every method is on one global interface, and our testing API should not look that way either. I would like to see our test API split up more, rather than combined into a single interface. Yeah, that'll be nice. Maybe morrita and dglazkov have an idea on how to do this nicely? I kind of like this plan: https://bugs.webkit.org/show_bug.cgi?id=76423 :DG I'm also confused about your examples of interfaces you are obviously removing. Did you mean obviously not removing? Sorry. Yes, it should read obviously NOT removing. - Ryosuke ___ 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?
(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
Re: [webkit-dev] When should we turn on new features?
On Tue, Feb 14, 2012 at 11:09 AM, 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. You are right. And talking about (1) is fine for this discussion to be focused. I went off the point. Regards, -- morrita 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
Re: [webkit-dev] Adding the Vibration API to WebCore
Hi, The first patch for this feature is almost ready: https://bugs.webkit.org/show_bug.cgi?id=72010 But I found that there is not so positive atmosphere here. Considering the feature is small and isolated enough and This API can be taken as a sort of Cookie for LocalStorage in the context of Gamepad API comparison, I personally feel that this change is OK to land. Please let this thread know if there are any concern or objection, otherwise I'll r+ this in this week. Also, if the author of original proposal has any discussion around the points that Adam and Simon raised, it would be helpful to drop it here for supporting this to happen. Thanks, -- morrita On Fri, Nov 11, 2011 at 7:37 AM, Simon Fraser simon.fra...@apple.com wrote: On Nov 10, 2011, at 5:57 AM, 권기홍 wrote: Hi webkit-dev. I want to let you know that I plan to add the Vibration API to WebKit. (http://dev.w3.org/2009/dap/vibration/) This support will be behind the ENABLE_VIBRATION feature define. see : https://bugs.webkit.org/show_bug.cgi?id=72010 Spec is not mature because it's recently added. But Mozila is already implemented this. I'm going to support this until finishing both the spec and patch. If you have any comment, please let me know. For game pads that have vibration feedback, there's obviously a tie-in with the joystick API here: https://lists.webkit.org/pipermail/webkit-dev/2011-August/017757.html Simon ___ 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] Asking for review by pinging bugs---another approach
Does it make sense for webkit-patch post/upload to support --ping to acknowledge a set of reviewers using a specific form of comment? As a reviewer, some kind of specific pattern would be helpful to filter such ping mails which contain, for example, ping:morrita@. Maybe this can be taken as a step backward to the by name review request which we had declined. But at least for me, such kind of filterable mail would be gret tool to pick bugs for review. Even though this won't help some high-traffic reviewers, it won't hurt at least. I've been overwhelmed by the stream of Bugzilla mail coming... What do you think? -- morrita On Thu, Jan 5, 2012 at 5:03 PM, Andreas Kling kl...@webkit.org wrote: On Thu, Jan 5, 2012 at 7:49 AM, Adam Barth aba...@webkit.org wrote: Not to pick on anyone in particular, but when reading bugmail I occasionally see messages like pinging for review. I review a lot of patches, but I don't find these messages particularly helpful because I don't know whether I'm supposed to review the patch. Another approach that might work better for you is to address your comment at someone in particular. For example, if the message says Adam, can you please review this patch?, then there's a pretty good chance I'll click through and try to answer your question. If you're unsure who to ask for review, one approach is to look at the svn log for the files you're changing and see who has written/reviewed patches for those files recently. You can also ask folks who've been around the project for a while to suggest someone. True that. You can also find reviewers for a particular area here on the WebKit Team wiki page: http://trac.webkit.org/wiki/WebKit%20Team (and I encourage people to keep their entry up-to-date.) -Kling ___ 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] Incremental steps towards moving WebCore/platform out of WebCore
One concern is that Platform is too generic to put in global namespace and it might conflict existing symbols from platform SDK or something. But because we already have generic names like ASSERT() and it works, this concern is just a theoretical thing. So if it works with existing platforms, I think it's fine. -- morrita On Thu, Dec 15, 2011 at 4:02 PM, Jarred Nicholls jar...@webkit.org wrote: On Thu, Dec 15, 2011 at 1:55 AM, Adam Barth aba...@webkit.org wrote: I was working backwards from what's going to be needed to move WebCore/platform out of WebCore, and it occurred to me that we'll probably want a separate namespace for the code once it's outside of WebCore, just like WTF has a separate namespace from JSC. It seems like introducing the new namespace before the move would be beneficial because it would help us sort out whatever layering violations we have today (as they'd become apparent because of the explicit mention of the WebCore namespace). What would be an appropriate name for the namespace? My first instinct is Platform to match the name of the new directory, but I'm open to suggestions. I think Platform is good. When explaining it to an outsider, I refer to it as the Client Interface or Port Interface. If Platform doesn't resonate well with everyone then maybe something around that verbiage would fit. But honestly I can't think of anything better than Platform. Adam ___ 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] Replacing symbol files with source level annotations
Hi folks, I'm working on replacing the symbol lists with source-level annotations. And I'd like to ask for your help and review the work. The first target is JavaScriptCore.exp since JSC is smaller than WebCore thus easier to attack, and the Mac port maintains the most comprehensive symbol list. My plan is to use an automation tool for rewriting the code. The tool inserts JSC_EXPORT_PRIVATE and its variants for functions and variables whose symbols are specified in JavaScriptCore.exp. Here is the current result: * The tool: https://github.com/omo/ListExportables README.txt explains how to run it.Note that it's for Mac OS and Mac port. * A snapshot diff of the generated rewrite: https://bugs.webkit.org/show_bug.cgi?id=72855 * To make the rewrite build-able, we need to land a few changes: * https://bugs.webkit.org/show_bug.cgi?id=72862 * https://bugs.webkit.org/show_bug.cgi?id=72853 * https://bugs.webkit.org/show_bug.cgi?id=72858 After applying these changes, rewritten code can be built on Mac Snow Leopard without the export list. I guess it's also buidable for other versions of Mac with no ... or few modifications. The advantages of this automate rewrite are: * We can write whole JSC code at once. So the result is verifiable before landing it. * We can land it anytime. For example, I can run the script and land the result at the weekend midnight. This would minimize the impact of landing. * There are fewer chances to over-export and miss-export symbols because the rewrite locations are based on the exp file. I'd like to ask, especially for some Mac build expert ... * Please try the rewrite result. You can run the tool by yourself, or I can generate the result for specific revision of WebKit for you. * Please review blocking problems: http://webkit.org/b/72862, http://webkit.org/b/72853, http://webkit.org/b/72858 I think these are trivial and is no harm to land this even without the rewrite. * Once the idea looks OK for you, rubberstamp the rewrite result ;-) Once this rewrite is in the tree. it would be easy to attack other ports like GTK and Windows. There are some remaining tasks for using this tool against WebCore. But I think JSC is a good starting point. Here is the master bug: https://bugs.webkit.org/show_bug.cgi?id=67852 Any advice, feedbacks and reviews are welcome! I hope our frequent build breakers to retire. -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Simplifying hub classes (was Cleaning up directories in WebCore)
One traditional pattern is to split a big class into a set small classes plus a hub class like how Adam has done for original Frame. In that pattern, small classes has a reference to the hub class and know its API. I hope these small classes know just a small part of its hub class via interface (abstract class.) In that way, such classes can be unit-tested independently without instantiating the hub class, whose instantiation is typically a difficult job. Personally, I feel that we don't need category-like mixin mechanism for existing hub classes. Since we have just a few or dozen of instances of these classes and the size overhead from extra pointers is negligible. It isn't case for the node family though. -- morrita On Sun, Nov 20, 2011 at 2:23 AM, Adam Roben aro...@apple.com wrote: On Nov 18, 2011, at 5:55 PM, Adam Barth wrote: Really, SQL_DATABASE just wants to store some state per ScriptExecutionContext. It seems like there should be a way to do that without making a mess of ScriptExecutionContext. IMHO, we want something like the C++ equivalent of Objective-C categories. I'm not sure how best to achieve that. Note that ObjC categories don't allow you to add extra state (i.e., ivars) to classes. They only allow you to add extra methods. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Change to style guideline: should use type instead of type* for out arguments
At least we already have some of such mehods like: void Range::getBorderAndTextQuads(VectorFloatQuad) const; void VisiblePosition::getInlineBoxAndOffset(InlineBox* inlineBox, int caretOffset) const; void Posiiton::getInlineBoxAndOffset(EAffinity, InlineBox*, int caretOffset) const; void FrameView::getTickmarks(VectorLayoutRect) const; bool Editor::getCompositionSelection(unsigned selectionStart, unsigned selectionEnd) const; On Wed, Oct 5, 2011 at 10:14 AM, Eric Seidel e...@webkit.org wrote: Interesting. I thought historical policy was universally against the word get in function names. I guess you're suggesting that get should only be applied to function names which have an out-argument? I once heard such a feed back on some review. And at least we already have some of such mehods like: void Range::getBorderAndTextQuads(VectorFloatQuad) const; void VisiblePosition::getInlineBoxAndOffset(InlineBox* inlineBox, int caretOffset) const; void Posiiton::getInlineBoxAndOffset(EAffinity, InlineBox*, int caretOffset) const; void FrameView::getTickmarks(VectorLayoutRect) const; bool Editor::getCompositionSelection(unsigned selectionStart, unsigned selectionEnd) const; ...and more: http://codesearch.google.com/codesearch#search/exact_package=chromiumq=WebCore%20get.%2B%20file:h$ Personally prefer the get prefix for function with out-params since it's hard to feel it like an attribute/member variable. This is never a strong claim though. Regards, -- morrita -eric On Tue, Oct 4, 2011 at 6:00 PM, Darin Adler da...@apple.com wrote: On Oct 4, 2011, at 2:06 PM, Ryosuke Niwa wrote: It came to my attention that some people are using raw pointers to pass out-arguments (e.g. bug 69366). In my understanding, we use pass by reference for out arguments when they have to be modified in callees. If there's no objection, I'm going to file a bug upload a patch to state this explicitly in the style guideline. If it’s not already in there, I think you might also want to mention the related rule that encourages the use of the word “get” at the starts of the names of these functions with out arguments. -- 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 -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Spellcheck code cleanup
Hi folks, My team is planning to simplify spellchecking code in WebCore by migrating old code path to new code path. I'd like to hear your advice before moving forward. Background: Currently WebCore has two separate logics for spellchecking. The first version relies on TextCheckerClient::checkTextOfParagraph(), which is available Snow Leopard or later. We call it unified version since the code path is guarded by USE(UNIFIED_TEXT_CHECKING). Another version only uses simpler (but less powerful) API like TextCheckerClient::checkSpellingOfString(). We call it legacy version. Although both unified and legacy version have almost same role, their code paths are completely different and are mutual exclusive. Unified version is inside #if block and legacy is in #else. This makes it hard to change editing code because we need to take care of both but we cannot check both at once. Our goal is to make the code simpler by removing legacy path and replacing it with unified path. It should be possible by implementing checkTextOfParagraph() equivalent with other TextCheckerClient API. Here is a tracking bug for this: https://bugs.webkit.org/show_bug.cgi?id=65849 I uploaded prototype version of the change. Theoretically, this can be a harmless one-shot change. But we're worrying about unexpected side effect thus we'd like to do it in small steps. Here is a rough plan: Step 1: Add Setting::isUnifiedTextCheckerEnabled(), which is true only for platform who has checkTextOfParagraph(). Step 2: Implement Editor::checkTextOfParagraph() which wraps TextCheckerClient::checkTextOfParagraph() and replace TextCheckerClient::checkTextOfParagraph() call with Editor's indirection. Step 3: Replace compile-time flag #if USE(UNIFIED_TEXT_CHECKING) with the runtime-flag check using isUnifiedTextCheckerEnabled(). This is only for files under editing/. Step 4: Implement TextCheckerClient::checkTextOfParagraph() equivalent in Editor::checkTextOfParagraph(), which is used with platforms which don't have TextCheckerClient::checkTextOfParagraph(). Step 5: Flip isUnifiedTextCheckerEnabled() to true on Chromium (maybe behind the experimental flag.) Then see how it works. Step 6: Stabilize (Hopes there is no need to do it ;-)) Step 7: Once step 6 goes well, flip isUnifiedTextCheckerEnabled() for all platforms, maybe behind the compilation flags like ENABLE_EDITOR_UNIFIED_TEXT_CHECKING. Step 8: Remove legacy code path and the runtime flag. Possible side effects in my mind are: A: Temporal code size growth Since we enable both legacy and unified code path, it can impact the code size. But in practice, the grows is around a few hundred lines of code and there is no template heavy class. Thus the impact seems negligible. B: Performance impact. This change can affect performance since the unified version requires larger text chunks to check spelling when the grammar checker is enabled. This affect only Leopard since it is the only platform that has grammar checker but doesn't have unified checker. And in my understanding, Safari disables grammar checker by default. So this looks to affect only small number of people who 1.use Leopard 2.enable grammar checking 3.use latest WebKit. And the spellchecking only happens by typing, and there is no batch spellcheck. Thus it would be little recognizable difference in real use. From my personal viewpoint, Step 1-5 looks fine, but 6-8 may be controversial. How do you think? Any feedback is appreciated. Regards, -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
