I am the maintainer of djvulibre on a mission to make the djview plugin work inside rekonq.
Working under kubuntu precise (rekonq 0.9.1)
1) HOW TO MAKE IT WORK
Best is to use the latest git version
$ git clone git://djvu.git.sourceforge.net/gitroot/djvu/djview.git
Convenient packages at http://leon.bottou.org/morefiles/ if you want to save time.
2) WHAT IS THE PROBLEM
There are in fact three ways for rekonq to show djvu files.
1- Using the okular part. This is broken on kubuntu 12.04. Also you do not get the menus.
2- Using the nsplugin part that comes with konqueror. This is broken too.
3- Directly using the djview plugin. This is the one I can fix. It works.
The problem is that rekonq only uses the djview plugin if it finds nothing in the kde file associations for embedding data of mime type vnd.djvu. Otherwise it tries to use the kde parts that fail for reasons well beyond my competences.
The worst part is that the user has no way to indicate that he would prefer using the direct plugin support from webkit, because this code path is not represented in the file association dialog. If the konqueror nspluginviewer is installed, the file association shows an entry "Netscape plugin" but this entry is for the nsplugin part which should load the plugin but does it in a way that does not work in rekonq (although it works in konqueror).
As long as the kpart support is incomplete (menubar merging?), it makes sense to prefer the netscape plugins over the kparts. Maybe with a preference option to control this priority.
- Leon Bottou
Hi Leon, and many thanks for your interest about.
Anyway, I'm not sure what is the main problem here. While reading I just tried loading in a new tab the link you gave me without any other change to configuration or package compiling/installation. Result: it just works in my local rekonq! Screenshot following.
Can you please suggest a link where you don't see it working?
Created attachment 73121 [details]
rekonq showing the link with okular part
Created attachment 73123 [details]
okularpart inside rekonq
Kubuntu 12.04. Okularpart inside rekonq appears black This changes when one resizes the window
Created attachment 73126 [details]
okularpart on an indirect djvu document
Okular cannot show a so-called indirect djvu document, because multiple http requests are necessary to fetch the document pages on demand.
Attachment 73123 [details] illustrates how okularpart appears inside rekonq when viewing a djvu file under kubuntu 12.04. It is not very eventful, as you can see. Note that the okular part is displayed correctly as soon as you resize the rekonq window. But where are the menus? How do I select text in the djvu document? Even when it works, the functionality is incomplete.
Also, viewing djvu files inside a browser is expected to obey various pseudo-cgi options to control what is shown. For instance, clicking on <http://leon.bottou.org/publications/djvu/jmlr-2011.djvu?djvuopts&page=4&zoom=133> is expected to show page 4 with a 133% zoom factor. There are quite a lot of these options (see http://djvu.sourceforge.net/doc/man/djview4.html). The most important is certainly the "page=xxxx" option. Many sites do not work right without this.
Also there are djvu documents that do not come as a single file but as a collection of files that are loaded on demand by the djvu viewer. This allows random access in large documents.Attachment 73123 [details] shows how okularpart looks like when you click on <http://leon.bottou.org/cgi/djvuserve/publications/djvu/jmlr-2011.djvu/index.djvu>, after suitably resizing the window to get out of the "black" state.
Please do not misread me. Okular is fine as a standalone app to view djvu files stored on your hard disk. But it does not implement all the things that DjVu does to help viewing documents online (the above, plus progressive rendering, caching and prefetching.)
But even there, I would say that okular is a reasonable default when the djview plugin is not installed. But what is an unsuspecting user to do when encountering one of these sites? We cannot even tell the user to install the djvu plugin because the part takes precedence over the plugins. You'd think it is enough to raise the position of the "Netscape Plugin" line in the file association tab. But no, this increases the priority of the nsviewpluginpart that comes with konqueror and does not work well in rekonq either (it works inside konqueror.)
It took me a couple hours to realize that the plugin support of rekonq is working very well, and that the only problem was to make sure it would not attempt to load a part when I want the plugin. I wanted to draw the attention of the rekonq people about this simple fact.
what do you think about the attached (super easy) patch?
Created attachment 73148 [details]
let rekonq use djvu plugin..
If this does what i think it does, this would certainly does the trick when the (correct) djvu plugin is installed. The downside is that we get no djvu support without the djview plugin. At least this is simple to explain. But I cannot help but feel that this is not the "right" way because we take options away from the user.
* Note that there is a similar function in kdewebkit already (see excludeMimeType in http://gitorious.org/dbusmenu/kdelibs/blobs/master/kdewebkit/kwebpluginfactory.cpp).
* What about a checkbox in the config dialog that gives preference to plugins over parts in general? I guess the problem is that you do not know which mimetypes are supported by a netscape plugin. This seems hidden in the depths of webkit :-(. They do not even let you configure the plugin search path!
* The presence of the konqueror-nsplugins package makes things confusing because the file association kde settings now show a "netscape plugin part" option to embed a file. Maybe the webpluginfactory could return zero when the kmimetypetrader finds this part.
Well, just ideas, and not very satisfactory either...
Yes, excludeMimeType is exactly what I did in this simple patch.
As you stated, the problem is that we don't know npapi plugins installed by code in qtwebkit. So, we have to decide before. Fortunately, rekonq has a structure, called "ProtocolHandler", that manage the link/urls webkit cannot manage. So, applied the patch you can add/remove djvu plugin and see that rekonq uses plugin/part (plugin via webpluginfactory if it is available, part via protocolhandler, if the link has not been rendered via webkit (or its plugins)
here is the patch I'm going to merge with your ok. Regards,
Created attachment 73156 [details]
yet easy, but clean patch to merge
The protocol handler is for fullpage parts, not embeds, correct?
But I guess this is okay because the okular part works poorly for embeds anyway.
Thanks a thousand times.
Git commit 3b7a1ffae0ae9e5fd0c1dd238434e0bf312fa6ad by Andrea Diamantini.
Committed on 14/08/2012 at 10:57.
Pushed by adjam into branch 'master'.
Get sure rekonq makes use of djvu plugin
Also, clean up mimetype detection, following kdewebkit.
I tried implementing this using the protected excludeMimeType in
kwebpluginfactory, but I fear it has to be declared virtual to let
the trick work. Isn't it?
M +13 -1 src/webpluginfactory.cpp
M +1 -1 src/webpluginfactory.h