To support GTK+ 2 plugins we had to build the plugin process with GTK+ 2, but also some parts of WebCore and WebKit2 (the ones depending on GTK+ and used by the plugin process) were built twice. As a result we had a WebKitPluginProcess binary of ~40MB, that was always used for all the plugins. This kind of made sense, since there were no plugins using GTK+ 3, and the GTK+ 2 dependency was harmless for plugins not using GTK+ at all. However, we realized we were making a rule for the exception, since most of the plugins don’t even use GTK+, and there weren’t plugins using GTK+ 3 because they were not supported by any browser (kind of chicken-egg problem).<\/p>\n
Since WebKitGTK+ 2.5.1<\/a> we have two binaries for the plugin process: WebKitPluginProcess2 which is exactly the same 40MB binary using GTK+ 2 that we have always had, but that now is only used to load plugins using GTK+ 2; and WebKitPluginProcess, a 7,4K binary that is now used by default for everything except loading plugins that use GTK+ 2. And since it links to GTK+ 3, it might load plugins using GTK+ 3 as well. Another side effect is that now we can make GTK+ 2 optional<\/a>, WebKitPluginProcess2 wouldn’t be built and only plugins using GTK+ 2 wouldn’t be supported.<\/p>\n For a long time, we have maintained that PDF documents shouldn’t be opened inside the browser<\/a>, but downloaded and then opened by the default document viewer. But then the GNOME design team came up with new mockups for Epiphany<\/a> were everything was integrated in the browser, including PDF documents. It’s something all the major browsers do nowadays, using different approaches though (Custom PDF plugin inside the web engine, JavaScript libraries, etc.).<\/p>\n At the WebKitGTK+ hackfest in 2012<\/a> we started to think about how to implement the integrated document reading in Epiphany based on the design mockups. We quickly discarded the idea of implementing it as a NPAPI plugin, because that would mean we had to use a very old evince version using GTK+ 2. We can’t implement it inside WebKit using libevince because it’s a GPL library, so the first approach was to implement it inside Epiphany using libevince. I wrote a first patch<\/a>, it was mostly a proof of concept hack, that added a new view widget based on EvView to be used instead of a WebView when a document supported by evince was requested. This approach has a lot of limitations, since it only works when the main resource is a document, but not for documents embedded in a HTML page or an iframe, and a lot of integration problems that makes it quite difficult to maintain inside Epiphany. All of these issues would be solved by implementing it as a NPAPI plugin and it wouldn’t require any change in Epiphany. Now that WebKitGTK+ supports GTK+ 3 plugins, there’s no reason not to do so.<\/p>\n Thanks to a project in Igalia<\/a> I’ve been able to work on it, and today I’ve landed an initial implementation of the browser plugin to Evince git master<\/a>. It’s only a first implementation (written in C++ 11) with the basic features (page navigation, view modes, zoom and printing), and a very simple UI that needs to be updated to match the mockups. It can be disabled at compile time like all other frontends inside Evince (thumbnailer, previewer, nautilus properties page).<\/p>\nEvince Browser Plugin<\/h2>\n
![\"Epiphany](\"http:\/\/blogs.igalia.com\/carlosgc\/files\/2014\/08\/ephy-evince-plugin-277x300.png\")
<\/a><\/p>\n
![\"Epiphany](\"http:\/\/blogs.igalia.com\/carlosgc\/files\/2014\/08\/ephy-pdf-embedded.png\")
<\/a><\/td>\n![\"Epiphany](\"http:\/\/blogs.igalia.com\/carlosgc\/files\/2014\/08\/ephy-pdf-standalone.png\")
<\/a><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n