[Webkit-unassigned] [Bug 55719] [Qt][WK2] Make Qt port compiling with ENABLE_PLUGIN_PROCESS=1

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=55719





--- Comment #43 from Balazs Kelemen <kbalazs at webkit.org>  2011-03-11 06:55:53 PST ---
Huhh, complex text handling is complex. I'm still unsure about the purpose of the whole logic i.e
I'm unsure about it is needed for supporting exotic languages or it is just an optimization for situations when
the simple code path can be used. Actually the plugin part is seems to be really needed for supporting non-regular
text with plugins (i.e. we need to wait for the whole string to arrive before sending it to the plugin).
However I hardly think that it is even possible for X based plugins.
The complex text is sent to the plugin here (on Mac):
-> NetscapePluginMac.cpp
void NetscapePlugin::sendComplexTextInput(const String& textInput)
{
    switch (m_eventModel) {
    case NPEventModelCocoa: {
        NPCocoaEvent event = initializeEvent(NPCocoaEventTextInput);
        event.data.text.text = reinterpret_cast<NPNSString*>(static_cast<NSString*>(textInput));
        NPP_HandleEvent(&event);
        break;
    }
...

But we have to work with XKeyEvent that cannot store a unicode string.
According to that I didn't see anything in the Qt and GTK WK1 plugin code that deals with complex text.

The complex text story exists on WK1 as well at the WebKit level but it is used by only Mac and Windows.
Here is some grep output:
./mac/WebKit.order:2464:+[WebView(WebPrivate) _setAlwaysUsesComplexTextCodePath:]
./mac/WebView/WebView.mm:1019:    [self _setAlwaysUsesComplexTextCodePath:f];
./mac/WebView/WebView.mm:1022:+ (void)_setAlwaysUsesComplexTextCodePath:(BOOL)f
./mac/WebView/WebViewPrivate.h:340:+ (void)_setAlwaysUsesComplexTextCodePath:(BOOL)f;
./win/Interfaces/IWebViewPrivate.idl:156:    HRESULT setAlwaysUsesComplexTextCodePath([in] BOOL complex);
./win/Interfaces/IWebViewPrivate.idl:157:    HRESULT alwaysUsesComplexTextCodePath([out, retval] BOOL* complex);
./win/WebView.h:750:    virtual HRESULT STDMETHODCALLTYPE setAlwaysUsesComplexTextCodePath(
./win/WebView.h:753:    virtual HRESULT STDMETHODCALLTYPE alwaysUsesComplexTextCodePath(
./win/WebView.cpp:5853:HRESULT STDMETHODCALLTYPE WebView::setAlwaysUsesComplexTextCodePath(BOOL complex)
./win/WebView.cpp:5855:    WebCoreSetAlwaysUsesComplexTextCodePath(complex);
./win/WebView.cpp:5860:HRESULT STDMETHODCALLTYPE WebView::alwaysUsesComplexTextCodePath(BOOL* complex)
./win/WebView.cpp:5865:    *complex = WebCoreAlwaysUsesComplexTextCodePath();

According to special circumstances they call WebCore::Font::setCodePath (static function) to statically
anchor the path to use. I guess it is about optimizing the simple case and avoid having to decide the path
for every text run.

In summary I think we should not deal with that now but leave it as a Mac specific thing.
This way we can set up the build with a less complex patch.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.