Description: This software implements a plugin for Netscape-compatible browsers in a Unix environment. This plugin uses KDE's KParts technology to embed file viewers (e.g. for PDF files) into non-KDE browsers. Tested browsers include both Mozilla Firefox and Opera. With this plugin, you can e.g. view PDF files in Firefox using Okular as an embedded plugin.Last changelog:
2012-07-23 * Applying patch by Arno Rehn to avoid blacklisting in Oxygen-transparent style
2012-06-05 * Using URL to create a default filename when saving copy of document * Minor change in UI to place long mime type labels in one line * Adding push button to copy URL into clipboard
2012-05-29 * Fixing some minor compilation errors * Adding KCModule (System Settings module) to configure which mime types shall be supported, removing this option from the plugin itself
2012-05-24 * Rearranging GUI to be more compact vertically * Porting from KBibTeX support for custom keyboard shorts * Refactoring drop-down menu to tree view for mime type configuration
2012-04-22 * Adding patch by Rex Dieter set installation directory by parameter to cmake * Fixing print menu item issue for Okular part * Menus and toolbars know separators now
2012-04-19 * Various minor changes * Adding experimental support for menus and toolbars from embedded part
2012-04-11 * Adding various mimetypes to blacklist
2011-08-23 * Blacklisting some more Java mimetypes: application/java-archive and video/x-javafx
2011-08-06 * Minor code clean-up and refactoring (no functional changes)
2011-06-06 * Added .pot file for translations (no actual translations yet)
2010-12-16 * Adding "application/googletalk" to blacklisted mime types
2010-12-08 * Adding "application/futuresplash" to blacklisted mime types * Checking if mime type is valid when reading data to avoid crash * Minor tweaks in user interface strings
2010-07-23 * Manually raising dialog to select part (if multiple KParts available for same mime type) * Minor GUI improvements
2010-07-22 * Showing current mime type in GUI (right to buttons) * Adding more mime types to built-in blacklisted list ("application/force-download", everything starting with "x-") * Adding release date to internal description (see "about:plugins" in Firefox)
2010-07-06 * Marking some mime types as built-in blacklisted, e.g. application/x-shockwave-flash * Adding more mime types to built-in blacklist to avoid problems with Thunderbird
2010-06-29 * Adding dialog to choose which KPart to use if several parts are available. User can set preference to avoid getting this dialog again for the same mime type.
2010-06-27 * Adding comments throughout the code * Enabling/disabling mime types possible in GUI (new push button with menu) * Improved focus handling using code from Jeremy Sanders * Make installation path 32/64-bit aware * Minor GUI improvements
2010-06-04 * Major refactoring * Supported mime types determined through KDE-internal functions; hard-coded list no longer necessary * Adding support for keyboard focus. Tip from Jeremy Sanders (http://barmag.net/)
2010-06-02 * Saving file failed if part was not loaded properly.
2010-06-01 * CMakeLists.txt contains a variable with installation directory * New script src/generate-mimetype-includes.sh to enhance "raw" source files to final files containing a list of objects (one for each supported mime type) List of mime types can be controlled via text file src/mimetypes.txt * Showing a list of compiled-in/supported mime types while waiting for the file's data * Open and save buttons are available even if no part is available to show the file's data * Fixing warnings
Hello, a few hours ago chromium-browser was updated to version 34, and the NPAPI was completely removed. This means that the upcoming Ubuntu 14.04LTS and variants will be unable to have kpartsplugin on chromium-browser.
1. Choose a file which can be opened with a kpart.
2. Remove all kparts associated with it.
3. Open such a file in the browser.
Kpartsplugin crashes.
Moreover, if the file type does not have any associated kparts anymore, it does not appear in the kpartsplugin configuration module, so you cannot configure it not to be opened with kpartsplugin.
This plug-in is great and I enjoy having embedded Okular in Firefox very much. The only issue is that menubar and toolbar take some vertical space, and I don't use either of them very often: my typical pdf-file browsing session is "open the file, read some parts, then close it". It would be really great for me to have "Disable UI" option in right-click menu, which will hide menubar, toolbar, and maybe even pagebar, leaving only the content of a file and scrollbar. Then pdf file viewing in Firefox would be really like reading an ordinary web page.
Other commenters proposed a right-click menu option to disable only toolbar or only menubar. I would be happy with this too (and page bar hiding is already implemented).
One more thing, which is probably impossible: what about special "performance" settings for Okular? It has a choice of memory usage politics, and while having "Normal" or "Aggressive" mode in a standalone viewer is OK, forcing embedded okular windows to switch to "Low" memory usage seems reasonable (as an option, indeed). I have to admit that this is very okular-specific and given that (as far as I know, but I may be wrong) okular doesn't support different modes in different instances, the idea looks improbable, but still there may be some way.
Thank you for your work on the plug-in which makes browsing a lot more convenient. I often have to look through pdf files linked from web and using KParts+Okular instead of a clumsy and somewhat slow Adobe Reader plug-in for Firefox is very nice.
it would be great to have it working in rekonq. to put an exemple, okular is much more powerful in kpartsplugin than in the embedded okular window in rekonq...
Hi,
Thank you very much for making this great app! I enjoy it very much.
I'm delighted to see toolbars have been added, I just can't figure out how to turn them on, for Ocular in particular.
Thanks in advance for any help.
Kind regards,
John
Versions:
KParts 20120723
Ocular 0.14.3
Firefox 16.0.1
KDE 4.8.5
OpenSUSE 12.2
Hey,
When I use this plugin everything shows up in a separate X window for some reason now. I believe this has to do with Qt style I am using, called Bespin (rev 1607).
I would really really really appreciate it if this could be fixed. :)
At the moment I am using Kubuntu 12.04 with KDE 4.8.5. It *should* be reproducible only with Bespin however.
My Bespin configuration. (~/.config/Bespin/Style.conf)
http://pastebin.com/YBsLNPKJ
Bespin URL. (You'll need to build from source :( )
http://kde-look.org/content/show.php?content=63928
Screenshot below.
http://i.imgur.com/X46cl.png
I'm getting the following Firefox output, (specifically when the plugin is running). I don't know/think it helps much though.
http://pastebin.com/j3rHEn5Y
Well, if it happens with Bespin only, then it is obviously a Bespin problem and you should contact its author.
As for Firefox, I don't see why it should have changed with a newer version, as the plugin is not specific to any Firefox version. I am not using Firefox 15 myself, but my guess would be that it is some sort of settings problem. Try to contact the Sumo people about that ...
Sorry, I should have tested this without Bespin enabled to begin with. The problem doesn't appear on the Oxygen style, so it might be Bespin afterall. Yes, I have already contacted the author (I'm working the bug report on 2 fronts, just to make sure everything that needs to be done is done).
The person who is testing this problem out was also having the plugin freeze on him (besides my issue). He says the following:
"i suggest to file a bug for the plugin to
setenv("QT_NO_GLIB", "") before (likely creating a QApplication instance."
You can see my bug report for his style here:
http://sourceforge.net/tracker/?func=detail&aid=3564916&group_id=201276&atid=976907
The paths were all wrong. It was installing the plugin to /usr/lib/nsbrowser and /usr/local for the others. I switched it to /usr/lib/mozilla and /usr, and it installed to the correct places. It took a lot of work though.
Is there any easier way I can manually configure the path seamlessly for future releases?
There are two variables that determine where KPartsPlugin is installed to and both are provided when calling cmake using a switch like -D VARIABLE=VALUE
The installation path for the browser plugin itself is controlled by NSPLUGIN_INSTALL_DIR and the default value is /usr/lib*/nsbrowser/plugins/
The KCM and other files are installed into a subtree defined in CMAKE_INSTALL_PREFIX which is /usr/local by default.
For more details on KDE and CMake, have a look here: http://techbase.kde.org/Development/CMake
great plugin!It really makes kde appear less a second class citizen in the desktop environment arena!
I hope to see it bundled with more distro soon.
Just some feedback from an old kde user:
1. why the kcm mdoule? AFAIK you don't need to create it, you can make kpartsplugin be a viewer in the default file association module by adding just a .desktop file. For example, the x-chm mime-type is handled by okularpart. This association is defined insied /usr/share/kde4/services/okularChm.desktop file.
2. the toolbar and the menubar are not right-clckable (at least for okular). Is it a wanted behaviour? Since its a plugin it would be wonderful to be able to enable/disable the menubar.
Just my two cents, thanks for this great little utility!
> great plugin!It really makes kde appear less a
> second class citizen in the desktop environment
> arena!
KDE was never a second class citizen!
> why the kcm mdoule? AFAIK you don't need to
> create it, you can make kpartsplugin be a
> viewer in the default file association module
> by adding just a .desktop file.
You got it wrong where KPartsPlugin comes into play. It is not meant to replace Okluar, it makes Okular accessible from within your non-KDE browser.
KPartsPlugin will claim support in the browser for any mimetype which is supported in the KDE system, which is maybe not what you want. For example, KPartsPlugin will claim to support all kinds of office file formats as soon as Calligra is installed, but you may want to prefer LibreOffice's native plugin you browser. Simply use the KCM module to tell KPartsPlugin to step back.
> the toolbar and the menubar are not right-
> clckable (at least for okular). Is it a wanted
> behaviour? Since its a plugin it would be
> wonderful to be able to enable/disable the
> menubar.
Well, I have to admit it: The menu/tool bar is fake and just rebuilds the original one at its bare minimum. Feel free to contribute code how to improve it.
However, I could add an option to the KCM module to add options for (not) showing buttons or menus ...
> You got it wrong where KPartsPlugin comes into
> play. It is not meant to replace Okluar, it
> makes Okular accessible from within your
> non-KDE browser. KPartsPlugin will claim
> support in the browser for any mimetype
> which is supported in the KDE system,
> which is maybe not what you want. For
> example, KPartsPlugin will claim to support
> all kinds of office file formats as soon as
> Calligra is installed, but you may want to
> prefer LibreOffice's native plugin you
> browser. Simply use the KCM module to tell
> KPartsPlugin to step back.
Actualy I didn't looked at the sources,
I thought you implemented it as
a kpart plugin itself (even if, thinking on
it, doing something like that
would have not made possible to manage
mime-type handling the way I was suggesting
either)
>> the toolbar and the menubar are not right-
>> clckable (at least for okular). Is it a anted
>> behaviour? Since its a plugin it would be
>> wonderful to be able to enable/disable the
>> menubar.
>
> Well, I have to admit it: The menu/tool bar
> is fake and just rebuilds the original one
> at its bare minimum. Feel free to contribute
> code how to improve it.
> However, I could add an option to the KCM
> module to add options for (not) showing
> buttons or menus ...
Many "kpart container" applications (I mean
konsole, dolphin, okular etc) use the standard
actions "show/ihde" menubar and "show/hide"
toolbar. Ithink a better approach would be to
let kpartsplugin behave the same. I hope to
find some spare time soon to add support for
this point.
PS:
>KDE was never a second class citizen!
well, for me it's the King of DE, but I have
yet to see major distributions (fedora,ubuntu,
and even opensuse to some extent) make a better
use of its technologies. Seems that all of the
fine tuning love is directed elsewhere, and
you as a kde user are forced to fiddle with
stupid details all the time just to make things
work toghether.
Hi, I'm using it on Arch and it works great. For the most part, it's made my life easier. I like opening pdf files that I only intend to read once directly on the browser without having to save it to disk.
However, I've found that it complicates things for me with files that I already know I want to keep. Before, I used to click on the link to the file and presto! I would get the "save file" dialog pre-populated with the original filename, so it took just another click to save the file.
With the plugin enabled, I see the contents of the file, but there's no "one-click" way of saving it to disk with the original filename. The "save copy..." button opens the "save dialog," but the filename is empty, so I have to manually type it in--or copy/paste it from the url. Using the save menu from the external program used to open the file gets me the "save dialog" with a made-up name (e.g. KPartsPluginSF3360.pdf). The only way I have to save it with its original name (without typing anything) is going to the Firefox menu > "save page as..." and that's pretty inconvenient.
So my question is, is there a way to preserve the original filename and pre-populate the "save copy" dialog with it? Or have another button for it, or any other solution that gets me a quick way to save a file directly from the page I'm seeing without having to go to the FF menu?
Thanks.
Ratings & Comments
140 Comments
According to http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html, Chrome will remove NPAPI support starting with version 35. Is there any plan for PPAPI support?
Hello, a few hours ago chromium-browser was updated to version 34, and the NPAPI was completely removed. This means that the upcoming Ubuntu 14.04LTS and variants will be unable to have kpartsplugin on chromium-browser.
That's a shame. Is there no alternative? https://superuser.com/q/1075075/904401 doesn't provide much hope.
1. Choose a file which can be opened with a kpart. 2. Remove all kparts associated with it. 3. Open such a file in the browser. Kpartsplugin crashes. Moreover, if the file type does not have any associated kparts anymore, it does not appear in the kpartsplugin configuration module, so you cannot configure it not to be opened with kpartsplugin.
Dear dev, kparts-plugin is pure magic. I cannot believe how it enhances my productivity in Firefox. I just love the power of KDE. Thank you!
I want it to open PDF, but it has taken over all kinds of file types. How do I tell it only PDF?
You could just keep it disabled (no restart required in Firefox) and then enable it when you have a pdf to look at. I do that sometimes.
This plug-in is great and I enjoy having embedded Okular in Firefox very much. The only issue is that menubar and toolbar take some vertical space, and I don't use either of them very often: my typical pdf-file browsing session is "open the file, read some parts, then close it". It would be really great for me to have "Disable UI" option in right-click menu, which will hide menubar, toolbar, and maybe even pagebar, leaving only the content of a file and scrollbar. Then pdf file viewing in Firefox would be really like reading an ordinary web page. Other commenters proposed a right-click menu option to disable only toolbar or only menubar. I would be happy with this too (and page bar hiding is already implemented). One more thing, which is probably impossible: what about special "performance" settings for Okular? It has a choice of memory usage politics, and while having "Normal" or "Aggressive" mode in a standalone viewer is OK, forcing embedded okular windows to switch to "Low" memory usage seems reasonable (as an option, indeed). I have to admit that this is very okular-specific and given that (as far as I know, but I may be wrong) okular doesn't support different modes in different instances, the idea looks improbable, but still there may be some way. Thank you for your work on the plug-in which makes browsing a lot more convenient. I often have to look through pdf files linked from web and using KParts+Okular instead of a clumsy and somewhat slow Adobe Reader plug-in for Firefox is very nice.
it would be great to have it working in rekonq. to put an exemple, okular is much more powerful in kpartsplugin than in the embedded okular window in rekonq...
Hi, Thank you very much for making this great app! I enjoy it very much. I'm delighted to see toolbars have been added, I just can't figure out how to turn them on, for Ocular in particular. Thanks in advance for any help. Kind regards, John Versions: KParts 20120723 Ocular 0.14.3 Firefox 16.0.1 KDE 4.8.5 OpenSUSE 12.2
Hey, When I use this plugin everything shows up in a separate X window for some reason now. I believe this has to do with Qt style I am using, called Bespin (rev 1607). I would really really really appreciate it if this could be fixed. :) At the moment I am using Kubuntu 12.04 with KDE 4.8.5. It *should* be reproducible only with Bespin however. My Bespin configuration. (~/.config/Bespin/Style.conf) http://pastebin.com/YBsLNPKJ Bespin URL. (You'll need to build from source :( ) http://kde-look.org/content/show.php?content=63928 Screenshot below. http://i.imgur.com/X46cl.png
I'm getting the following Firefox output, (specifically when the plugin is running). I don't know/think it helps much though. http://pastebin.com/j3rHEn5Y
From my recent testing, this problem looks like it is related to the new Firefox 15 rather.
Well, if it happens with Bespin only, then it is obviously a Bespin problem and you should contact its author. As for Firefox, I don't see why it should have changed with a newer version, as the plugin is not specific to any Firefox version. I am not using Firefox 15 myself, but my guess would be that it is some sort of settings problem. Try to contact the Sumo people about that ...
Sorry, I should have tested this without Bespin enabled to begin with. The problem doesn't appear on the Oxygen style, so it might be Bespin afterall. Yes, I have already contacted the author (I'm working the bug report on 2 fronts, just to make sure everything that needs to be done is done).
The person who is testing this problem out was also having the plugin freeze on him (besides my issue). He says the following: "i suggest to file a bug for the plugin to setenv("QT_NO_GLIB", "") before (likely creating a QApplication instance." You can see my bug report for his style here: http://sourceforge.net/tracker/?func=detail&aid=3564916&group_id=201276&atid=976907
In the git version, I added a simple unsetenv("QT_NO_GLIB"); Please test if this new version fixes you "out-of-window" problems.
Well, it happens with oxygen-transparent style, too. The kpart "pops out" of the window. It happens in Firefox as well as in Opera.
The paths were all wrong. It was installing the plugin to /usr/lib/nsbrowser and /usr/local for the others. I switched it to /usr/lib/mozilla and /usr, and it installed to the correct places. It took a lot of work though. Is there any easier way I can manually configure the path seamlessly for future releases?
There are two variables that determine where KPartsPlugin is installed to and both are provided when calling cmake using a switch like -D VARIABLE=VALUE The installation path for the browser plugin itself is controlled by NSPLUGIN_INSTALL_DIR and the default value is /usr/lib*/nsbrowser/plugins/ The KCM and other files are installed into a subtree defined in CMAKE_INSTALL_PREFIX which is /usr/local by default. For more details on KDE and CMake, have a look here: http://techbase.kde.org/Development/CMake
Awesome! Thanks! I vaguely remember that's how to do it, but I had since forgotten. Thanks for the reminder!
great plugin!It really makes kde appear less a second class citizen in the desktop environment arena! I hope to see it bundled with more distro soon. Just some feedback from an old kde user: 1. why the kcm mdoule? AFAIK you don't need to create it, you can make kpartsplugin be a viewer in the default file association module by adding just a .desktop file. For example, the x-chm mime-type is handled by okularpart. This association is defined insied /usr/share/kde4/services/okularChm.desktop file. 2. the toolbar and the menubar are not right-clckable (at least for okular). Is it a wanted behaviour? Since its a plugin it would be wonderful to be able to enable/disable the menubar. Just my two cents, thanks for this great little utility!
> great plugin!It really makes kde appear less a > second class citizen in the desktop environment > arena! KDE was never a second class citizen! > why the kcm mdoule? AFAIK you don't need to > create it, you can make kpartsplugin be a > viewer in the default file association module > by adding just a .desktop file. You got it wrong where KPartsPlugin comes into play. It is not meant to replace Okluar, it makes Okular accessible from within your non-KDE browser. KPartsPlugin will claim support in the browser for any mimetype which is supported in the KDE system, which is maybe not what you want. For example, KPartsPlugin will claim to support all kinds of office file formats as soon as Calligra is installed, but you may want to prefer LibreOffice's native plugin you browser. Simply use the KCM module to tell KPartsPlugin to step back. > the toolbar and the menubar are not right- > clckable (at least for okular). Is it a wanted > behaviour? Since its a plugin it would be > wonderful to be able to enable/disable the > menubar. Well, I have to admit it: The menu/tool bar is fake and just rebuilds the original one at its bare minimum. Feel free to contribute code how to improve it. However, I could add an option to the KCM module to add options for (not) showing buttons or menus ...
> You got it wrong where KPartsPlugin comes into > play. It is not meant to replace Okluar, it > makes Okular accessible from within your > non-KDE browser. KPartsPlugin will claim > support in the browser for any mimetype > which is supported in the KDE system, > which is maybe not what you want. For > example, KPartsPlugin will claim to support > all kinds of office file formats as soon as > Calligra is installed, but you may want to > prefer LibreOffice's native plugin you > browser. Simply use the KCM module to tell > KPartsPlugin to step back. Actualy I didn't looked at the sources, I thought you implemented it as a kpart plugin itself (even if, thinking on it, doing something like that would have not made possible to manage mime-type handling the way I was suggesting either) >> the toolbar and the menubar are not right- >> clckable (at least for okular). Is it a anted >> behaviour? Since its a plugin it would be >> wonderful to be able to enable/disable the >> menubar. > > Well, I have to admit it: The menu/tool bar > is fake and just rebuilds the original one > at its bare minimum. Feel free to contribute > code how to improve it. > However, I could add an option to the KCM > module to add options for (not) showing > buttons or menus ... Many "kpart container" applications (I mean konsole, dolphin, okular etc) use the standard actions "show/ihde" menubar and "show/hide" toolbar. Ithink a better approach would be to let kpartsplugin behave the same. I hope to find some spare time soon to add support for this point. PS: >KDE was never a second class citizen! well, for me it's the King of DE, but I have yet to see major distributions (fedora,ubuntu, and even opensuse to some extent) make a better use of its technologies. Seems that all of the fine tuning love is directed elsewhere, and you as a kde user are forced to fiddle with stupid details all the time just to make things work toghether.
Hi, I'm using it on Arch and it works great. For the most part, it's made my life easier. I like opening pdf files that I only intend to read once directly on the browser without having to save it to disk. However, I've found that it complicates things for me with files that I already know I want to keep. Before, I used to click on the link to the file and presto! I would get the "save file" dialog pre-populated with the original filename, so it took just another click to save the file. With the plugin enabled, I see the contents of the file, but there's no "one-click" way of saving it to disk with the original filename. The "save copy..." button opens the "save dialog," but the filename is empty, so I have to manually type it in--or copy/paste it from the url. Using the save menu from the external program used to open the file gets me the "save dialog" with a made-up name (e.g. KPartsPluginSF3360.pdf). The only way I have to save it with its original name (without typing anything) is going to the Firefox menu > "save page as..." and that's pretty inconvenient. So my question is, is there a way to preserve the original filename and pre-populate the "save copy" dialog with it? Or have another button for it, or any other solution that gets me a quick way to save a file directly from the page I'm seeing without having to go to the FF menu? Thanks.