Version: (using KDE 4.2.90) Installed from: SuSE RPMs I try to open epub file, but okular says it cannot open it (and in the hint -- plugin is missing). It would be useful to add info about some default plugin, so the user would know what to look for. This would also make a difference for the formats which are not supported by okular at all. See for example: https://bugs.kde.org/show_bug.cgi?id=194945 Pino commented that the epub is supported, but due to the same error message it is not possible to tell by normal user (not Okular dev).
(In reply to comment #0) > I try to open epub file, but okular says it cannot open it (and in the hint -- > plugin is missing). If you have no backend able to read epub documents, you get that message. > It would be useful to add info about some default plugin, so the user would > know what to look for. There's no such thing as "default plugin". There is Okular, finding plugins for itself, and using them when applicable. > This would also make a difference for the formats which are not supported by > okular at all. > > See for example: > https://bugs.kde.org/show_bug.cgi?id=194945 > > Pino commented that the epub is supported, but due to the same error message it > is not possible to tell by normal user (not Okular dev). "epub is supported" means there is (somewhere, from somebody, which is us in epub's case) a backend supporting the epub format. But, from Okular's point of view, no existing backend for a format or existing and not installed is the very same thing.
> "epub is supported" means there is (...) a backend supporting the > epub format. And this piece of information makes the difference. If you know as dev, that there is somewhere, some, by someone, etc. plugin to format X it would be good to display such information. Or maybe it would be good to point out a link to the webpage of known plug-ins (in both cases). I opt for latter solution.
(In reply to comment #2) > > "epub is supported" means there is (...) a backend supporting the > > epub format. > > And this piece of information makes the difference. Actually, it does not (see below). > If you know as dev, that > there is somewhere, some, by someone, etc. plugin to format X it would be good > to display such information. > > Or maybe it would be good to point out a link to the webpage of known plug-ins > (in both cases). I opt for latter solution. Telling "epub is supported" to the user is pointless, when the distro of the user does not provide that plugin (for whatever reason, distros should have good reasons to not provide a plugin). Showing a page with "epub is supported" won't magically bring that plugin to the user, which just consider the situation as "okular does not support epub". Also, Okular cannot tell "error when loading foo.epub, becuase there is no plugin installed; install one", because there's no way for Okular to know that exists some plugin for that format. Okular just knows which plugins it has, and which format they support.
Is listing known plugins for Okular possible? Yes. So it would be good to refer to such page. In such case user could take a look and notice there is not known plugin for xyz, so the chance it exists are 0.001%. If the plugin is known then it is very likely it just digging it out. I am aware how plugins mechanism works, but also I am aware that you have some knowledge average user does not have. So why not to share it?
(In reply to comment #4) > Is listing known plugins for Okular possible? Yes. No, given that anybody can write an own plugin for some format, and make it Okular use it with no problems. And second point, I refuse to hardcode names of plugins, as it would just defeat the point of plugins. We have already such a page[0], which just lists the plugins we (only) develop. But, as already said, this does not improve the situation for distros which don't ship any of those we provide. [0] http://okular.kde.org/formats.php
> And second point, I refuse > to hardcode names of plugins, as it would just defeat the point of > plugins. I agree, that is why I opted for naming only the web page. > [0] http://okular.kde.org/formats.php Thank you. So the message would be "Plug-in not found. You can refer to page [0]". It is more helpful than current situation.
That page isn't a complete list of plugins - it can't ever be, because users can write their own. This is a packaging issue.
> That page isn't a complete list of plugins - it can't > ever be, because users can write their own. Brad, I know. Little help is better than no help at all.
I think you need to think about the "misleading help is worse than no help" angle.
> I think you need to think about the "misleading help > is worse than no help" angle. What is misleading here? If you know the plugin A exists, you list it. That's it. You said it yourself "This is a packaging issue." How do you know it is packaging issue? And even if -- how packager is able to package the plugins? After all it shouldn't be possible if the listing of plugins is impossible (according to you). For comparison, impossible to do web page: http://www.sane-project.org/sane-mfgs.html
Thanks for caring to report this wish, but what you are asking for is technically impossible hence i'm closing this report. Thanks again.