Bug 304562

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.

Hello Andrea,

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.

Thanks.

 - L.

Hi leon,
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...

Thanks.

- L.

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

OK.

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.

- L.

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?
CCMAIL: adawit@kde.org

M  +13   -1    src/webpluginfactory.cpp
M  +1    -1    src/webpluginfactory.h

http://commits.kde.org/rekonq/3b7a1ffae0ae9e5fd0c1dd238434e0bf312fa6ad