Re: [webkit-dev] Hunspell based spellchecker
On Wednesday 17 November 2010 04:52:36 Hajime Morita wrote: Hi WebKit folks, I'm thinking about porting Hunspell-based spellchecking code from Chromium to WebKit/WebCore. The Qt folks on the list can correct me if I'm wrong but this would be very welcome for Qt. I don't see how a WebCore spellchecker could be anything but a good thing! ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Hunspell based spellchecker
On Wednesday 17 November 2010 04:52:36 Hajime Morita wrote: Hi WebKit folks, I'm thinking about porting Hunspell-based spellchecking code from Chromium to WebKit/WebCore. At least in the Windows implementation (WebKit/WebKit source base), the spell checker is implemented on the client side as a delegate operation. I wrote up a few notes on the topic (http://whtconstruct.blogspot.com/2010/07/spelling.html). What would be the advantage in placing the spell checker in WebCore, as opposed to the relatively agnostic approach used via the WebKit API? Is there a performance benefit, or a means of hooking into some other part of the system not currently served by the existing spelling infrastructure? -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [Bug 26083] How to access formatted Java script Console message ?
Hi All, My patch failed on cr-linux. I am still setting up my chromium environment to try it out. I would appreciate if some can provide pointers on how to fix this: In file included from WebCore/page/Console.cpp:39: JavaScriptCore/runtime/PropertyNameArray.h:24: fatal error: CallFrame.h: No such file or directory compilation terminated. make: *** [out/Release/obj.target/webcore_remaining/WebCore/page/Console.o] Error 1 make: *** Waiting for unfinished jobs I tried both options: #include PropertyNameArray.h and #include runtime/PropertyNameArray.h. But, looks like it didn’t resolve on cr-linux. Regards, -- Gopal -Original Message- From: ext bugzilla-dae...@webkit.org [mailto:bugzilla-dae...@webkit.org] Sent: Wednesday, November 17, 2010 4:21 PM To: Raghavan Gopal.1 (Nokia-MS/Boston) Subject: [Bug 26083] How to access formatted Java script Console message ? https://bugs.webkit.org/show_bug.cgi?id=26083 --- Comment #17 from WebKit Review Bot webkit.review@gmail.com 2010-11-17 13:21:06 PST --- Attachment 74128 did not build on chromium: Build output: http://queues.webkit.org/results/6113029 -- Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Hunspell based spellchecker
Hi, Multiple ports can share the implementation if we put spell checker in WebCore. Ports without native spell checker can use Hunspell based spell checker without much efforts. Brew MP port is also interested because it does not have a native spell checker. Regards, Kwang Yul Seo On Thu, Nov 18, 2010 at 5:27 AM, Brent Fulgham bfulg...@gmail.com wrote: On Wednesday 17 November 2010 04:52:36 Hajime Morita wrote: Hi WebKit folks, I'm thinking about porting Hunspell-based spellchecking code from Chromium to WebKit/WebCore. At least in the Windows implementation (WebKit/WebKit source base), the spell checker is implemented on the client side as a delegate operation. I wrote up a few notes on the topic (http://whtconstruct.blogspot.com/2010/07/spelling.html). What would be the advantage in placing the spell checker in WebCore, as opposed to the relatively agnostic approach used via the WebKit API? Is there a performance benefit, or a means of hooking into some other part of the system not currently served by the existing spelling infrastructure? -Brent ___ 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] OSX build break after system update
I attempted to write a clean-room implementation of jni.h. I've admitted defeat. A ridiculously complicated header. Installing the Java SDK now (to bring the commit-queue back online) and sad about the burden to the project. Hopefully Apple will ship the Java SDK as part of XCode to fix this silly build requirement. -eric On Tue, Nov 16, 2010 at 10:57 PM, Eric Seidel e...@webkit.org wrote: Stubbing out the headers in an easy way. I've still not updated my build machine due to this. But it's generally hard to build w/o signing up for an apple id since the latest XCode generally requires one. -eric On Tue, Nov 16, 2010 at 9:10 PM, Luke Macpherson macpher...@chromium.orgwrote: This is preventing me from building. Is there a solution that doesn't require signing up for an Apple ID? On Fri, Oct 29, 2010 at 3:17 AM, Tony Gentilcore to...@chromium.org wrote: On Wed, Oct 27, 2010 at 10:11 PM, Eric Seidel e...@webkit.org wrote: Can we just include the headers in WebKit? Or find some way to auto-download them? +1 This seems silly. Or certainly requiring an update to http://webkit.org/building/tools.html. In the meantime, there is: https://bugs.webkit.org/show_bug.cgi?id=48423 -eric On Thu, Oct 21, 2010 at 3:56 PM, Tony Gentilcore to...@chromium.org wrote: Quick PSA: if you install the Java for Mac OS X 10.6 Update 3 system update you may start getting build errors like: error: JavaVM/jni.h: No such file or directory The solution is to install Java for Mac OS X 10.6 Update 3 Developer Package from http://connect.apple.com Downloads Java [1]. Thanks andersca for the solution! -Tony [1] This link might work: http://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wo/5.1.17.2.1.3.3.1.0.1.1.0.3.8.3.3.1 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Hunspell based spellchecker
Hi everyone, thank you for your feedback! Now I know there are some positive interest to Hunspell integration. So I'll start investigation and come back once I have some progress. @bflgham What would be the advantage in placing the spell checker in WebCore, as opposed to the relatively agnostic approach used via the WebKit API? Is there a performance benefit, or a means of hooking into some other part of the system not currently served by the existing spelling infrastructure? As @kwangyul.seo mentioned, the primary advantage of WebCore-ization is code sharing. Having it, you can get working integration with few effort. And yes, if you already have your own implementation, there might be no direct benefit. As a developer's standpoint, centralizing spellcheck related code into WebCore will make it much easier to work on spellchecking related codebase. As you know, touching every ports' EditingClient implementation is plain pain. It is another story though. -- morrita -Brent ___ 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] Gtk EWS
Seems very broken: http://queues.webkit.org/results/6184043 Could someone fix build-webkit or whatever piece is looking for the missing Makefile? -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Hunspell based spellchecker
Safari on Windows provides a spelling checker outside of WebKit. If we change the way spelling checking is organized inside WebKit, we need to preserve that feature in the WebKit used by Safari on Windows. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Gtk EWS
On Wed, Nov 17, 2010 at 10:14 PM, Eric Seidel e...@webkit.org wrote: Seems very broken: http://queues.webkit.org/results/6184043 Could someone fix build-webkit or whatever piece is looking for the missing Makefile? I believe that my patch at https://bugs.webkit.org/show_bug.cgi?id=49400 may have wedged the EWS. I've checked the patch in now, so hopefully that should fix any lingering issues. If not, forcing a clean build should do the trick. Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Hunspell based spellchecker
On Thu, Nov 18, 2010 at 3:33 PM, Darin Adler da...@apple.com wrote: Safari on Windows provides a spelling checker outside of WebKit. If we change the way spelling checking is organized inside WebKit, we need to preserve that feature in the WebKit used by Safari on Windows. Thank you for pointing this out. In my understanding, windows port is using EditingDelegate implementation for EditorClient. I think we can also use same EditingDlegate to implement TextChecker (or something like that) interface. In other word, we should make sure that TextChecker interface can have subclasses both inside and outside WebCore. I need to investigate more to see whether it is possible. Anyway, I'll start keeping original EditorClient API, then try to remove unnecessary methods. The change looks too large to do it at once. -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Hunspell based spellchecker
On Nov 17, 2010, at 10:49 PM, Hajime Morita wrote: In other word, we should make sure that TextChecker interface can have subclasses both inside and outside WebCore. Yes, in this model the abstract base class inside WebCore will need a derived class inside Windows WebKit that then in turn calls outside of WebKit. But it is not appropriate to expose an class from WebCore directly as part of WebKit API. A WebCore class is an appropriate way for WebKit to connect to WebCore. It is not an appropriate way for WebKit to provide API. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [Bug 26083] How to access formatted Java script Console message ?
Gopal, PropertyNameArray.h is only available if the engine of choice is JavaScriptCore. Chromium is using V8 so the file included is not available - as the error indicates. Check the review comments in the bug for more details/hints. Regards, Laszlo From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of ext Gopal Raghavan Sent: Wednesday, November 17, 2010 5:52 PM To: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] [Bug 26083] How to access formatted Java script Console message ? Hi All, My patch failed on cr-linux. I am still setting up my chromium environment to try it out. I would appreciate if some can provide pointers on how to fix this: In file included from WebCore/page/Console.cpp:39: JavaScriptCore/runtime/PropertyNameArray.h:24: fatal error: CallFrame.h: No such file or directory compilation terminated. make: *** [out/Release/obj.target/webcore_remaining/WebCore/page/Console.o] Error 1 make: *** Waiting for unfinished jobs I tried both options: #include PropertyNameArray.h and #include runtime/PropertyNameArray.h. But, looks like it didn't resolve on cr-linux. Regards, -- Gopal -Original Message- From: ext bugzilla-dae...@webkit.orgmailto:bugzilla-dae...@webkit.org [mailto:bugzilla-dae...@webkit.org]mailto:[mailto:bugzilla-dae...@webkit.org] Sent: Wednesday, November 17, 2010 4:21 PM To: Raghavan Gopal.1 (Nokia-MS/Boston) Subject: [Bug 26083] How to access formatted Java script Console message ? https://bugs.webkit.org/show_bug.cgi?id=26083 --- Comment #17 from WebKit Review Bot webkit.review@gmail.commailto:webkit.review@gmail.com 2010-11-17 13:21:06 PST --- Attachment 74128 did not build on chromium: Build output: http://queues.webkit.org/results/6113029 -- Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Hunspell based spellchecker
On Thu, Nov 18, 2010 at 3:51 PM, Darin Adler da...@apple.com wrote On Nov 17, 2010, at 10:49 PM, Hajime Morita wrote: In other word, we should make sure that TextChecker interface can have subclasses both inside and outside WebCore. Yes, in this model the abstract base class inside WebCore will need a derived class inside Windows WebKit that then in turn calls outside of WebKit. But it is not appropriate to expose an class from WebCore directly as part of WebKit API. A WebCore class is an appropriate way for WebKit to connect to WebCore. It is not an appropriate way for WebKit to provide API. Hmm, I'm a bit confused - My last explanation looks not enough, so please let me clarify: - TextChecker is a similar to EditorClient. It will be placed in WebCore/platform/text, like EditorClient is in WebCore/page/. - And (imaginative) WebTextChecker (or TextCheckerWindows) will be in WebKit/win/WebCoreSupport, as WebEditorClient is in WebKit/win/WebCoreSupport. - WebTextChecker should use EditingDelegate, as WebEditorClient is using it now. In other word, This change will just extract TextChecker interface from EditrClient interface, and provide some default implementations of it in WebCore, as we have WebCore/page/EmptyEditorClient for EditorClient. I guess we don't have this Interface in WebCore + Implementation in WebCore and WebCoreSupport pattern yet, But I don't think it is such a huge jump from existing patterns, like Interface in WebCore + Implementation in WebCoreSupport. Does this make sense? -- morrita -- Darin -- morrita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
