[webkit-dev] Followup to the WML discussion
Hi webkit-dev, To make progress on the question of whether to remove support for WML, I sent an informal poll the the WebKit reviewers mailing list. (In the interests of transparency, I've included the full text of the email below.) The poll contained a single question: 1. Should WebKit support WML? A) Yes, WebKit should continue to support WML behind ENABLE(WML) B) No, WebKit should remove support for WML 17 reviewers responded to the poll, and all 17 chose option (B). This poll is not a binding vote in any way, but, based on this information, I recommend that we remove support for WML. Thanks, Adam -- Forwarded message -- From: Adam Barth aba...@webkit.org Date: Wed, Apr 20, 2011 at 1:58 PM Subject: Poll about removing WML To: webkit-reviewers Hi webkit-reviewers, There's been some discussion on webkit-dev recently about whether we should remove support for WML. To get a sense for how the project leadership feels about removing support for WML, I've created a simple one-question poll: http://www.surveymonkey.com/s/xxx If you have an opinion about whether WebKit should support WML, please take a minute to fill out the poll. (If you don't have an opinion, please feel free to ignore the poll.) This poll is not a binding vote in any way. I'd just like to informally gather some data on how folks who are deeply involved with the project feel about this feature. I'll send out the results of the poll to webkit-dev on Sunday morning (in advance of the WebKit meeting). Thanks everyone, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] OSX 64 bit plugin support not ready
I'm working in the WebKit sources that comes down with Qt 4.7.3
I was trying to get the Adobe Square 64 bit flash plug-in (beta) to work in any
of the examples (currently I'm trying examples/webkit/fancybrowser)
While stepping through code, I found the following in
src/3rdparty/webkit/WebCore/plugins/mac/PluginViewMac.mm:
bool PluginView::platformStart()
// Gracefully handle unsupported drawing or event models. We can do this
// now since the drawing and event model can only be set during NPP_New.
#ifndef NP_NO_CARBON
NPBool eventModelSupported;
if (getValueStatic(NPNVariable(NPNVsupportsCarbonBool + m_eventModel),
eventModelSupported) != NPERR_NO_ERROR
|| !eventModelSupported) {
#endif
m_status = PluginStatusCanNotLoadPlugin;
LOG(Plugins, Plug-in '%s' uses unsupported event model %s,
m_plugin-name().utf8().data(),
prettyNameForEventModel(m_eventModel));
returnfalse;
#ifndef NP_NO_CARBON
}
#endif
...
Since NP_NO_CARBON is defined for 64 bit builds, the above code will set
m_status to PluginStatusCanNotLoadPlugin and return false.
Looking around some more, it turns out much of the code in this file is not
compiled if NP_NO_CARBON is defined. This leads me to believe that the version
of WebKit that comes down with Qt 4.7.3 is not ready for OSX 64 bit plugins.
I am new to the WebKit community so there is a lot I don't know about
resources,
development, source control, etc...
Be gentle.
So here are my questions:
1) Is the analysis correct? (i.e. 64 bit plugins not supported on OSX in this
WebKit branch)
2) How can I find out if this is being worked on? or if there are workarounds?
Thanks,
Alan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] OSX 64 bit plugin support not ready
I can't address your first question but have a comment. On Sun, Apr 24, 2011 at 2:46 PM, Alan Swartz alan_swa...@yahoo.com wrote: Looking around some more, it turns out much of the code in this file is not compiled if NP_NO_CARBON is defined. This leads me to believe that the version of WebKit that comes down with Qt 4.7.3 is not ready for OSX 64 bit plugins. You are aware that Carbon isn't available in 64 bits? Theoretically, a plugin with a Cocoa event model and CoreGraphics drawing should work, though the code you point out looks suspicious. Avi ___ 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
