[webkit-dev] Sending Composition events to Flash
Greetings WebKit developers, These days, I have been working for allowing users to use IMEs on windowless Flash on Win Safari and Win Chromium: http://webkit.org/b/64345 and http://webkit.org/b/61272. To describe this change briefly, these changes just send Composition events of DOM 3 (*1) to a plug-in element so the PluginView class can send WM_IME_STARTCOMPOSITION, WM_IME_COMPOSITION, and WM_IME_ENDCOMPOSITION) messages of Windows to Flash. (Flash calls Win32 functions to get IME text when it receives these messages.) Unfortunately, the current changes needed to copy some code (which sends Composition events to a plug-in element) from Editor::setComposition() to each platform-specific WebView code even though the code itself is not platform-specific. (It calls CompositionEvent::create() with text required by Flash and send it.) This is just because their WebView code returns when Editor::canEdit() returns false. (From the point of WebKit, a plug-in element is not editable.) To share their WebView code, I would like to change Editor::setComposition() so it sends Composition events and returns when the focused node is not editable. Also would I like to add a PlatformCompositionEvent class so CompositionEvent::create() can use it. Would it be possible to give me your thoughts? (*1) http://www.w3.org/TR/DOM-Level-3-Events/#events-compositionevents Regards, Hironori Bono E-mail: hb...@chromium.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Spellcheck API for WebKit
Greetings Simon, Apologies for my stupid change in advance. My change just tried to straightforwardly implement a suggestion http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0545.html without deep consideration about WebKit manners noted by your e-mail. On Wed, Jun 22, 2011 at 1:17 PM, Simon Fraser simon.fra...@apple.com wrote: This new API got turn on inadvertently on Mac just now, and a few of us spent a wasted hour trying to get things to build. In this light, my comments on the API may not be as favorable as they would otherwise be. First, why is the API on HTMLDivElement? Unfortunately, I have just copied and pasted my code in HTMLTextAreaElement to support contenteditable elements and designMode ones because I did not have better ideas at that time. I should have asked about it in this ML before landing this change. Second, since this exposes to the web API in a non-final spec, the new methods should be prefixed with 'webkit' to avoid potential conflict if the API changes later. This is totally my fault. (The sin of ignorance.) Sorry again for that. By the way, I wonder how I should treat my r88332 even though I understand this change was wrong. Even though there are several options: 1. re-design the API, 2. revert my r88332 and re-implement it, 3. send changes that apply these comments, etc. Would it be possible to give me your advice? Regards, Hironori Bono E-mail: hb...@chromium.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Spellcheck API for WebKit
Greetings Adam, Thank you for reverting this change on my behalf. (I agree it is not so easy.) I will re-implement this API to apply comments, wishing the next change becomes the better one. Regards, Hironori Bono E-mail: hb...@chromium.org On Thu, Jun 23, 2011 at 2:43 AM, Adam Barth aba...@webkit.org wrote: The rollout is slightly complicated, but I'll take care of it. Adam 2011/6/21 Ryosuke Niwa rn...@webkit.org: 2011/6/21 Hironori Bono (坊野 博典) hb...@chromium.org On Wed, Jun 22, 2011 at 1:17 PM, Simon Fraser simon.fra...@apple.com wrote: This new API got turn on inadvertently on Mac just now, and a few of us spent a wasted hour trying to get things to build. In this light, my comments on the API may not be as favorable as they would otherwise be. First, why is the API on HTMLDivElement? Unfortunately, I have just copied and pasted my code in HTMLTextAreaElement to support contenteditable elements and designMode ones because I did not have better ideas at that time. I should have asked about it in this ML before landing this change. contenteditable attribute can appear in any element so I don't think we should restrict it to div. Second, since this exposes to the web API in a non-final spec, the new methods should be prefixed with 'webkit' to avoid potential conflict if the API changes later. This is totally my fault. (The sin of ignorance.) Sorry again for that. By the way, I wonder how I should treat my r88332 even though I understand this change was wrong. Even though there are several options: 1. re-design the API, 2. revert my r88332 and re-implement it, 3. send changes that apply these comments, etc. Would it be possible to give me your advice? Given that the original patch seems to have various issues and we're going to make a lot of changes (i.e. move it to HTMLElement and prefix it with webkit or chrome), option 2 seems most suitable approach here. - Ryosuke ___ 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
Greetings Hajime-san, Even though this is out of this topic, from the point of a web-application developer, it would be great for WebKit to have a JavaScript API that encapsulates your spellchecker code so JavaScript can use it. Regards, Hironori Bono E-mail: hb...@chromium.org On Wed, Nov 17, 2010 at 1:52 PM, Hajime Morita morr...@google.com wrote: Hi WebKit folks, I'm thinking about porting Hunspell-based spellchecking code from Chromium to WebKit/WebCore. Although it's unclear whether the porting is feasible, I'd like to hear how much interest is there from other ports before starting actual work. Because the main goal is to make spellcheck available for more ports, It would be just a waste if there is no demand. For example, I heard that GTK+ has GtkSpell, which is based on Enchant. Because our code is based on Hunspell, GtkSpell based integration is out of scope of this proposal... I have no idea about Qt, EFL, etc. BTW, here is an under-half-baked-rough plan: - Extract spellcheck related methods on EditorClient, to interface (or abstract class) named, say, platform/text/TextChecker. - with keeping existing method, for compatibility - Add a getter like TextChecker* textChecker() = 0; to EditorClient. - Implement TextCheckerHunspell, a subclass of TextCheckerHunspell - TextCheckerHunspellChromium and some other variants will also be added, to make Chromium specific hooks. - (optional) Move Mac's spellchecker implementation from WebCoreSupport/WebEditorClient to platform/text/TextCheckerCocoa, another subclass of TextChecker. - (optional) Remove legacy methods on EditorClient This approach would make spellchecker pluggable, so WebKit can choose preferable spellchecker at runtime with this. (For example, Chromium port wants to use both Hunspell and system spellchecker. GTK port might want use Enchant and Hunspell.) Is this beneficial for your port? Are there other design possibilities? Any feedback is welcome. -- morrita ___ 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
