Building WebKit for GTK fails: WebCore/plugins/PluginView.cpp: In member function ‘NPError WebCore::PluginView::setValue(NPPVariable, void*)’: WebCore/plugins/PluginView.cpp:439: error: ‘m_drawingModel’ was not declared in this scope WebCore/plugins/PluginView.cpp:463: error: ‘m_eventModel’ was not declared in this scope WebCore/plugins/PluginView.cpp: In constructor ‘WebCore::PluginView::PluginView(WebCore::Frame*, const WebCore::IntSize&, WebCore::PluginPackage*, WebCore::Element*, const WebCore::KURL&, const WTF::Vector<WebCore::String, 0ul>&, const WTF::Vector<WebCore::String, 0ul>&, const WebCore::String&, bool)’: WebCore/plugins/PluginView.cpp:627: error: class ‘WebCore::PluginView’ does not have any field named ‘m_drawingModel’ WebCore/plugins/PluginView.cpp:628: error: class ‘WebCore::PluginView’ does not have any field named ‘m_eventModel’ WebCore/plugins/PluginView.cpp:649: error: ‘m_npCgContext’ was not declared in this scope (The line numbers are not correct for the current trunk; they refer to release 1.1.12. The underlying problem described below still exists.) It does so because PluginView.h contains the lines: #if PLATFORM(GTK) || defined(Q_WS_X11) void setNPWindowIfNeeded(); #elif defined(XP_MACOSX) NP_CGContext m_npCgContext; OwnPtr<Timer<PluginView> > m_nullEventTimer; NPDrawingModel m_drawingModel; NPEventModel m_eventModel; void setNPWindowIfNeeded(); void nullEventTimerFired(Timer<PluginView>*); Point globalMousePosForPlugin() const; #endif and PluginView.cpp has: #if defined(XP_MACOSX) case NPPVpluginDrawingModel: { // Can only set drawing model inside NPP_New() if (this != currentPluginView()) return NPERR_GENERIC_ERROR; NPDrawingModel newDrawingModel = NPDrawingModel(uintptr_t(value)); switch (newDrawingModel) { case NPDrawingModelCoreGraphics: m_drawingModel = newDrawingModel; return NPERR_NO_ERROR; ... #if defined(XP_MACOSX) , m_drawingModel(NPDrawingModel(-1)) , m_eventModel(NPEventModel(-1)) #endif When building with GTK and target=quartz, both GTK and XP_MACOSX are true. This was discussed at length in https://bugs.webkit.org/show_bug.cgi?id=17001. The initial error was committed in r43633 and r46028 added the member variables which induced the failure.
Created attachment 38583 [details] This patch allows PluginView.cpp to compile.
Created attachment 38768 [details] Patch v1
Hi John. Can you please try if the attached patch works for you? Thanks.
(In reply to comment #2) > Created an attachment (id=38768) [details] > Patch v1 Landed as http://trac.webkit.org/changeset/47882.
No, in fact it makes the situation much worse. Apparently you missed out on quartz being the native, non-X11, windowing system for OSX. It is a supported windowing system in Gtk. Regards, John Ralls
(In reply to comment #5) > No, in fact it makes the situation much worse. > > Apparently you missed out on quartz being the native, non-X11, windowing system > for OSX. It is a supported windowing system in Gtk. > > Regards, > John Ralls Are you able to provide a compile log this time? On Mac, WebKitGtk only support X11 plugins.
Created attachment 38823 [details] Error output from making webkit r47899 + config.log Sorry this took so long, I had to build a complete unstable Gtk tree to get the current WebKit SVN to build. I figured you didn't want to see the (probably bogus) results from my applying your patch to 1.1.12. You'll see from the error output that there are a bunch of X11-related macros which aren't defined, because I'm not building against X11. If WebKit Gtk doesn't support the quartz backend, then why does it have a configure option --target=quartz? Regards, John Ralls
Comment on attachment 38768 [details] Patch v1 Clearing review flag so it won't appear in the commit queue.
Created attachment 41762 [details] New patch against r49997 which restores ability of WebKit-GTK to build with target=quartz I've finally gotten back to working on this. This patch, against r50006, permits WebKit to build successfully with target=quartz and without X11. It passes all the unittests and GtkLauncher works. I'm not sure how well (or even if) plugins will work with this build: I haven't found any tests for them.
(In reply to comment #9) > Created an attachment (id=41762) [details] > New patch against r49997 which restores ability of WebKit-GTK to build with target=quartz > > I've finally gotten back to working on this. This patch, against r50006, permits WebKit to build successfully with target=quartz and without X11. It passes all the unittests and GtkLauncher works. I'm not sure how well (or even if) plugins will work with this build: I haven't found any tests for them. Hi John, don't you have issues compiling gtkxtbin.c (webkit 1.2.0 & 1.2.1) ? I ended up totally disabling it (see https://trac.macports.org/ticket/24622).
I haven't yet tried building 1.2.x; the last version I've built is 1.1.15.4; the patches to get that built are at http://github.com/jralls/gtk-osx-build/tree/master/patches/. Since 1.1.15.4 works fine for Gnucash's needs, I'm not likely to look at 1.2 until late this summer.
Quartz support will need to be worked into WebKit2GTK.