Version: 0.12 (using KDE 4.6.0) OS: Linux When you use the "Open with other application" option in the right click context menu on a file, the list is populated with 15 entries for okular. This seems to be because Okular installs multiple .desktop files in the ala-carte menu that are not activated. As far as I can tell, each menu entry functions exactly the same, as they each run the same command: `okular %U %i -caption "%c"' Please find a way to not install multiple menu entries. Reproducible: Always Steps to Reproduce: Install Okular from repositories, then try to open any file with the "Open With Other Application" option in the right click context menu. There will be >1 entry for Okular. Also, right click on Applications menu and select "Edit Menus", then look through the list to find multiple deactivated entries for Okular cluttering the menu editor up. Actual Results: Multiple entries for Okular in "Open With" dialog and menu editor. Expected Results: There should preferably be only one menu entry for each case. Launchpad may contain more information in its bug report, here: https://bugs.launchpad.net/ubuntu/+source/okular/+bug/456093
I already commented in that bug is a Nautilus bug for ignoring the NoDisplay entry
While that's true for the "Open With" menu, there still exists the issue of having 15 deactivated entries in ala-carte. The Nautilus guy had a valid point: Gnome doesn't display its PDF viewer (Evince) in the "Applications" menu, but Evince _does_ need to be shown in the "Open With" menu, because the user could have a file that needs to be opened in Evince. To me, this indicates that either the Evince/Gnome devs are abusing the .desktop standard, or Okular and Krita are the ones abusing the .desktop standard. And because Okular and Krita choose to install 15 menu entries, I figured they are probably the ones abusing the standard. You even admitted this in the Launchpad report: "Well, i can tell you that indeed okular has multiple .desktop files that might be causing this problem, probably that is a bit of "abuse" of the .desktop specification..." Nautilus needs to display all installed applications in the "Open With" menu, because an application may not have an installed Mimetype, but still be able to open a file. That's why they have to show all applications with .desktop files, such as 15 Okulars and 15 Kritas. "Okular installs lots of .desktop files it only installs one .desktop file that says is able to handle pdf files" - what use are the other .desktop files then? Why does Evince only need a single .desktop file to support similar documents? I'm not going to change the bug status because I don't want to get into a status-war with you, but I do think this bug should be reopened. Okular should not abuse the .desktop standard and expect other applications to work perfectly with it.
"Nautilus needs to display all installed applications in the "Open With" menu, because an application may not have an installed Mimetype, but still be able to open a file." This is a bug in said application. "Why does Evince only need a single .desktop file to support similar documents?" I have no idea how Evince works, but okular is plugin based, that is you can choose which plugins to install, thus it really makes 0 sense to have a single .desktop file advertising support for all file types, since well, it is not true "Okular should not abuse the .desktop standard and expect other applications to work perfectly with it." Can you really prove it is an abuse?
(In reply to comment #2) > Okular should not abuse the .desktop standard and expect other applications > to work perfectly with it. http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html Table 2. Standard Keys reads: <quote> NoDisplay means "this application exists, but don't display it in the menus". </quote> If whatever application ignores the NoDisplay entries in *.desktop files and adds the them to a context menu, it is from my PoV the one with the wrong behaviour wrt the .desktop standard.
Fine, that use case is a bug in that application, and it should be fixed. But, there is still another use case, where Evince doesn't want to be shown in the "Applications" menu, but still needs to be shown in the "Open With" menu. Unless there is an additional mechanism to tell Nautilus to display an application in the "Open With" menu, there's no way for Nautilus to know what to display and what not to display. Presumably Okular plugins can extend the functionality of Okular to open more formats than without the plugin, and therefore it's impossible to know which MIME types to register before the application launches. Thus, it does make sense to register additional MIME types for Okular when the plugins are installed, and the current way of doing this is by creating multiple desktop files. I am unsure what you are referring to when you speak of having me "prove its an abuse". I don't think I need to prove anything if you have already admitted that when you said "probably that is a bit of "abuse" of the .desktop specification" in the Launchpad bug report. On the point of abusing the standard, we seem to be in agreement, or seem to have agreed about this in the past. If your opinion has changed, I would like to know what changed it. However, it seems that this use case either needs an extension to the .desktop standard to differentiate between "Applications" menu and "Open With" menu, or Evince simply needs to have an "Applications" menu entry (eg: remove the NoDisplay from Evince, as it appears to be the only application in this use case). Would you agree with either of these solutions?
The easiest solution is to simply have Evince remove the NoDisplay=yes line in their .desktop entry. The relevant bug reports in the Gnome bug tracker are shown below (for anybody interested in following): https://bugzilla.gnome.org/show_bug.cgi?id=312399 https://bugzilla.gnome.org/show_bug.cgi?id=634245 (especially comment 7). Thanks for discussing this.
>>"Nautilus needs to display all installed applications in the "Open With" menu, >>because an application may not have an installed Mimetype, but still be able to >>open a file." >This is a bug in said application. > http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html > Table 2. Standard Keys reads: > <quote> > NoDisplay means "this application exists, but don't display it in the > menus". > </quote> > > If whatever application ignores the NoDisplay entries in *.desktop files > and > adds the them to a context menu, it is from my PoV the one with the wrong > behaviour wrt the .desktop standard. > > That is the sort of things that make me want to abandon once for all linux and opensource software in general and stick with Microsoft Windows (TM). When there is a bug, or a feature that does not work as expected, the maintainer of package A tells that the bug is in package B, and the maintainer of package B tells that the bug is in package A. The result is a holy war in which no one wins, giving that everyone blame the other and no-one fix the bug. As the final result, the bug is still there and the final end-user, who is not interested of whom the bug is or who is to blame because he just cannot understand the words "standard", "desktop file" and "NoDisplay entry" (yes, there are other subjects in real life, not only informatics) have to deal with it without no-one that fix it, and he ends leaving linux/ubuntu. A final user does not want to read both opinions and decide who is to blame, he just want to use his software out-of-the-box. Stop. And who makes a regular linux/ubuntu user angry is that the problem is not that we cannot find the bug and so we cannot fix it. The problem is that we (where 'we' means all the linux community) do not want to fix it, because the responsibility is of the other. Read this bug report: https://bugs.launchpad.net/ubuntu/+source/okular/+bug/456093. The package affected by the bug was changed 6 times. From okular to nautilus and back again. Of course this does not happen only to okular. It happens also to other packages and I am criticizing generally the way in which the open source community handle that sort of things. For example, plasma has a bug that make part of the screen black like there is a hole. But don't tell them of the bug: it's really a Xorg bug. And don't tell Xorg people they have a bug: it is not their fault if plasma developers cannot interface properly with Xorg. Proprietary softwares are not like this: one decide for all and things must work. in this way we are proving incontrovertibly that a software developed by a community without a superior that decide for all is not possible. We need a superior entity that decide who have the bug and who should fix it. I'm just saying that sort of things is ridiculous. When this things happen, we should work together and find a solution together, rather than blaming one another for who is right and who is wrong. As we say in Italy, "we are on the same ship". We all want to develop a free (in GNU sense) and open piece of software, and that should be the target. So just find a solution together. Ask freedesktop.org to specify what NoDisplay option really means. Then ask nautilus people to follow the standard. If they don't, find a workaround. Even if the counterpart does not want to talk, just find a workaround by our side. Who cares if we lose the holy war, we don't even wanted it to start.