WebKit/GTK+ with directFB

 The GTK+ port targets the cross-platform GLib and GTK+ APIs as well as related libraries. This means that it can be built against any of the windowing systems supported by GTK+ and Cairo without modification -- those tested so far are X11 and DirectFB. Code specific to any one backend should be conditionally compiled only when that windowing system is available. One examples of this kind of feature might be direct X11 use for plugin support.(Hacker's guide to WebKit/GTK+)


GTK+ with directFB is a GTK port which uses directFB as the backend. DirectFB provides drawing functions, a windowing stack, and manages input devices.


For the GTK port in WebKit, it wants to use XP_UNIX both in X11 and Mac.(GNUmakefile.am)

Most of WebKit does not depend on X, but, there was a tiny exception: NPAPI.

Netscape Plugin Application Programming Interface (NPAPI) is a cross-platform plugin architecture used by many web browsers. A plugin declares that it handles certain content types (e.g. "audio/mp3") through exposed file information. When the browser encounters such content type it loads the associated plugin, sets aside the space within the browser content for the plugin to render itself and then streams data to it. The plugin is then responsible for rendering the data as it sees fit, be it visual, audio or otherwise. So a plugin runs in-place within the page, as opposed to older browsers that had to launch an external application to handle unknown content types. The API requires each plugin to implement and expose a comparatively small number of functions. There are approximately 15 functions in total for initializing, creating, destroying, and positioning plugins.

As plugins are responsible for rendering themselves, they need to get a handle to the associated windowing system. On Linux, this implies a dependency on X regardless of your port in WebKit.

Thus for the GTK+directFB port in WebKit, your choice is either to disable all the code related to NPAPI by hands(there is no compile time switch) or to add the X11 dependency(for example, flash plugins use NPAPI so any site using it will be broken). Or, you'll see many compile errors related to the X missed:

./WebCore/bridge/npapi.h:273: error: ISO C++ forbids declaration of 'Display' with no type
./WebCore/bridge/npapi.h:273: error: expected ';' before '*' token
./WebCore/bridge/npapi.h:274: error: ISO C++ forbids declaration of 'Visual' with no type
./WebCore/bridge/npapi.h:274: error: expected ';' before '*' token
./WebCore/bridge/npapi.h:275: error: 'Colormap' does not name a type
./WebCore/bridge/npapi.h:597: error: 'XEvent' does not name a type
./WebCore/bridge/npapi.h:618: error: 'Region' does not name a type
./WebCore/bridge/npapi.h:865: error: 'NPRegion' has not been declared

How to solve it? My idea is to add the support of directFB within the definition of  XP_UNIX.
XP_UNIX is used in the following include files:

• WebCore/bridge/npapi.h
• WebCore/plugins/npfunctions.h
• WebCore/plugins/PluginView.h

If the WebKit is configured "--with-target=directfb", WTF_PLATFORM_DIRECTFB will be defined.



Therefore, we should can add the code for the file which calls X APIs:

#ifdef XP_UNIX
#ifdef WTF_PLATFORM_DIRECTFB

#else /* X */

#endif
#endif