GNOME Bugzilla – Bug 586040
duplicated command listed in open-with dialog
Last modified: 2010-06-07 13:34:08 UTC
(I don't know if the bug falls under the responsibility of nautilius or brasero, I'm opening against nautilus to start.) While looking in the list of applications available in the open-with dialog, I seen that brasero was listed several times, and with the same command. It seems to be weird to have the same command listed several times. baptiste@oak:~$ find /usr/share/applications -name brasero*.desktop -exec grep -H Exec {} \; /usr/share/applications/brasero-copy-medium.desktop:Exec=brasero -c %u /usr/share/applications/brasero.desktop:Exec=brasero %U /usr/share/applications/brasero-open-project.desktop:Exec=brasero -p %u /usr/share/applications/brasero-nautilus.desktop:TryExec=nautilus /usr/share/applications/brasero-nautilus.desktop:Exec=nautilus --no-default-window --no-desktop burn:/// /usr/share/applications/brasero-open-playlist.desktop:Exec=brasero -l %u /usr/share/applications/brasero-open-image.desktop:Exec=brasero -i %u
Created attachment 136769 [details] the illustration of the bug in open-with dialog
Should have caught this when I was doing the sort patch, but I didn't notice it. We're not checking if we should show the application in the dialog to begin with; almost all of those Brasero duplicates have 'NoDisplay=true'. Two-line patch to filter out these silly GAppInfos will fix this... (As soon as I update /everything/ to build nautilus here... heh).
*** Bug 566364 has been marked as a duplicate of this bug. ***
This seems like a broken application to me. Why can't it handle the different types of files with a single command-line, and figure out for itself whether it's a playlist, or an image.
Re-assigning to Brasero per last comment.
I remove three of all the offending desktop files and let brasero detect the file type and take the proper action. The only desktop file I left was for disc copy. I did this intentionally as it allows to have a better string than the default one ("Disc Copier" instead of "Disc Burner") in the Nautilus "what should I do?" dialog if you insert an audio disc. That said, I really think that nautilus should respect the 'NoDisplay=true' in the open-with dialog. This looks like a bug since the "fake" brasero desktop file will nevertheless appear in the dialog. What do you think?
Hi Philippe, NoDisplay=true is only intended for menu AFAIK, In order to hide entries in them, else menu would be overcrowed. Open-with serves another purpose, and should propose all desktop entries. Hiding entries with this field would be abusing the spec.
when I see brasero in the open with menu there are two entries both with the same command 'brasero' but in fspot's case one is fspot and other is fspot'import. so brasero have one extra entry.(although both entries have different description).(gnome 2.29.6)
*** Bug 609006 has been marked as a duplicate of this bug. ***
I am using GNOME 2.29.92 in Ubuntu 10.04 Beta and I currently have duplicates as well. Not too sure why this bug is assigned to brasero as it seems to affect multiple applications. Banshee x 3 Brasero x 2 F-Spot x 2 Remote Desktop Viewer x 2
I copied it from http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-1.0.html NoDisplay 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). (In reply to comment #7) > Hi Philippe, > > NoDisplay=true is only intended for menu AFAIK, In order to hide entries in > them, else menu would be overcrowed. > Open-with serves another purpose, and should propose all desktop entries. > Hiding entries with this field would be abusing the spec.
David, you're misinterpreting the spec (probably because it's ambiguous here): the menu mentioned in your quote is the applications menu. Your quote also mentions that this is useful to associate an app with a MIME type. Which is exactly what the open-with dialog is about.
Bug fixed in master. Brasero now detects it when a single URI or path passed on the command line refers to an optical disc and behaves accordingly. That made the second desktop file useless and I removed it.