Created attachment 4574 Screenshot of the problem. Some applications like Okular provide several .desktop files in /usr/share/applications/. All these files appear in the "Open with..." list of the file context menu, so you end up with what is seen on the attached screenshot. These duplicate .desktop files have the NoDisplay attribute set to true though, so they shouldn't appear in this menu. See also the discussion at https://bugs.launchpad.net/ubuntu/+source/okular/+bug/456093
Fixed in 159346a.
This breaks custom commands entered into "Open With...". Please find another way to fix it, or enhance the fix (e.g. set NoDisplay to false when desktop file is created, or ignore NoDisplay attribute for files in ~/.local/share/applications, or whatever).
Here is the userapp-feh.desktop file created by thunar: [Desktop Entry] Encoding=UTF-8 Version=1.0 Type=Application NoDisplay=true Exec=feh -Z --scale-down -B black %f %f Name=feh Comment=Benutzerdefinition für feh There is no OnlyShowIn, so maybe that's the problem?
(ignore the double %f please)
I think the title is partly incorrect. The word menu should be replaced with dialog. If one does not like certain applications (e.g. Epiphany) to appear in "Open with..." menu, they should add this to .local/share/applications/mimeapps.list [Removed Associations] text/xml=epiphany.desktop This is how it is being done with Nautilus.
AFAIK (which might not be much), the NoDisplay key is only for app menus. I thought it was meant exactly to have desktop files that would appear on right-click menus but not on apps menu. I think I got this impression from the Evince desktop file that had NoDisplay=true so it wouldn't appear on the app menu but would on the context menu for a PDF file.
Whatever extra stuff Okular is shipping it should be fixed there. I mean, are they shipping one desktop file for each MIME type it deals with? Then if that's the way KDE works, they should add OnlyShowIn=KDE to them and leave a normal desktop file with all MIME types for other DEs.
This is not specific to Okular. There are other applications with multiple entries (even thunar!). It's no good to start running after maintainers asking them to fix their desktop files. The reality is that you can't get rid of those multiple entries without dealing with them in thunar. Another related problem is this: I can create five different desktop files for the same command, using different parameters. Let's take 'feh' as an example: In the list the different commands will all appear as 'feh'. You won't know which parameters are used, so you have to try them one for one until you get lucky and hit the right one. For a similar example, think about a media player and it's typical actions (play file, enqueue,...). Perhaps this could be solved with an additional column that shows the command that will be run, or by showing that command in a tooltip.
I just wanna say that I posted in this bug report but I haven't actually examined the issue. So my apologies for that. I have really no idea about it.
I'm not really familiar with this stuff, so I'd like to ask, what is the official meaning (official as of the freedesktop standard) of the NoDesktop flag? Also, does anyone know what the idea behind multiple desktop files is? I mean, there must be some reason for their existence e.g. in the case of Okular. The example of several custom .desktop files for one command with different arguments seems not really representative to me, since such .desktop files should get different names specifying the action really being triggered. Otherwise, however the "Open with" list is implemented, there is no possibility for the user to find the correct launcher without looking at the actual command which is uncomfortable (think of the inexperienced user who doesn't know anything about commands and their start options).
Sorry, I meant "NoDisplay", not "NoDesktop".
Fixed again in 8aa0571.
Fix confirmed, custom applications work fine again.
Reverted a part of the fix, NoDisplay=true is for application menus, not for a file manager. The key is intended to hide MIME helpers from the menu, but obviously those should appear in Thunar. Se bug #9595
See also http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html
*** Bug 9595 has been marked as a duplicate of this bug. ***