GNOME Bugzilla – Bug 702681
Issues with applications marked as NoDisplay
Last modified: 2013-09-17 18:15:01 UTC
It looks like applications marked with NoDisplay does not show up in the Nautilus menus *unless* the application is mentioned in /usr/share/applications/defaults.list. I just ran into this problem when adding a new "Disk Image Writer" application to gnome-disk-utility, see https://git.gnome.org/browse/gnome-disk-utility/commit/?id=67c7e1ddd61f07c9bae36654ca73e309290eec39 https://plus.google.com/u/0/110773474140772402317/posts/Am7sBJqgEJh I think this is a bug in Nautilus - you should really ignore NoDisplay when determining if something appears in the "Open With" menu and other places. For now, I've just set NoDisplay=true in my desktop files until this is resolved. This is going to make Allan sad because he was the one who originally requested it, see bug 684550. I think the only reason it worked back then is because "Disk Image Mounter" was also in Fedora's /usr/share/applications/defaults.list file.
(In reply to comment #0) > I think this is a bug in Nautilus - you should really ignore NoDisplay when > determining if something appears in the "Open With" menu and other places. > > For now, I've just set NoDisplay=true in my desktop files until this is > resolved. I guess you mean "NoDisplay=false" - but I am not sure I agree with the bug report. This was changed in Nautilus only relatively recently [1]. Applications can use NoDisplay=true desktop files for many purposes, and we try to make the of applications displayed in that dialog consistent with what is displayed in the Shell and in e.g. the GtkAppChooser dialog, to reinforce the application-based mental model. I feel this is really a limitation of our desktop file-based entry point system for applications - a single application with its desktop file (in this case Disks) should be able to expose different entry points or "services" without the need to have multiple personalities with multiple desktop files. Not 100% sure what's the best way forward here - we could revert the "hide NoDisplay apps" patch, but that would create other inconsistencies as you can see in the original report. [1] https://bugzilla.gnome.org/show_bug.cgi?id=696372
My interpretation of NoDisplay is that it should only be taken into account for the traditional applications menu (Foot->Applications in GNOME 2) / shell application list. I think the description from http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html - that is NoDisplay means "this application exists, but don't display it in the menus". This can be useful to e.g. associate this application with MIME types, so that it gets launched from a file manager (or other apps), without having a menu entry for it (there are tons of good reasons for this, including e.g. the netscape -remote, or kfmclient openURL kind of stuff). support this interpretation. IOW, I think both Nautilus' "Open With" menu and GtkAppChooserWidget should display applications even if NoDisplay=true. I'm all for having a better system down the road and I'd be the first to support it in Disks... but I also think we need to fix this problem in 3.8 and onwards.. because it's going to take a while to get the new system implemented and people using it. (Another thing is that gnome-shell should be "smart" enough to skip both gnome-disk-image-writer.desktop it has a %U in the Exec line. IOW, it won't work without a URI passed to it. OTOH, gnome-disk-image-mounter.desktop has a %U but it works without an URL - it simply shows a file chooser dialog instead. Maybe we need a new desktop-file key for that, say, ArgumentsRequired=true|false.)
Btw, I'm also fine with a more low-tech solution such as adding X-GNOME-NoDisplayInShell=true to gnome-disk-image-mounter.desktop and gnome-disk-image-writer.desktop (while not setting NoDisplay=true). Solving the general problem - including debating on xdg-list - could take a loong time...
So we'd have to revert #696372, #696405 and https://git.gnome.org/browse/gtk+/commit/gtk/gtkappchooserwidget.c?id=84922d331768ba9046d9737dbe66468ac45d41f2 I guess. I don't think the Shell should do any additional second guess based on the ability of the app to open an URI, since as you say some apps might try to detect an empty URI and take another action. Matthias, Jon: any opinion?
(In reply to comment #4) > Matthias, Jon: any opinion? Guys?
Sorry, this fell through the cracks. I would be inclined to agree that if an app indicates in its desktop file that it can handle files of a certain type, we should offer the user a way to use it for that purpose in the appchooser dialog. Even if it is otherwise marked as NoDisplay.
(In reply to comment #2) > gnome-disk-image-writer.desktop it has a %U in the Exec line. IOW, it won't > work without a URI passed to it This bug is somewhat urgent because as David pointed out, gnome-disk-image-writer currently ships NoDisplay=false even though the launcher is nonfunctional within the shell.
*** Bug 705644 has been marked as a duplicate of this bug. ***
As described in bug 705644, Shotwell Photo Viewer cannot be associated with image files because of this bug.
Cosimo: with Matthias agreement in comment 6, any chance you can do the reverts you mentioned in comment 4? With that done, I'll add NoDisplay=true to the Disk Image writer / Disk Image mounter apps in gnome-disk-utility... and other people can do similar things. Thanks!
I think I'm inclined to agree with David's analysis in comment 2. Since the desktop entry spec specifically mentions that this key can/should be used for file helper utilities that aren't really apps which should appear in the app menu, I think it is reasonable to allow it for that purpose. Provided that we are consistent in our usage and honor Hidden and *ShowIn keys.
After r-t approval I pushed the reverts to gtk+ and nautilus master. Closing this as FIXED.