After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 107417 - Can't find name of .desktop file.
Can't find name of .desktop file.
Status: RESOLVED DUPLICATE of bug 688632
Product: nautilus
Classification: Core
Component: File and Folder Operations
3.1.x
Other other
: Normal minor
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 572436 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-03-02 21:15 UTC by Chris Lahey
Modified: 2018-05-09 16:43 UTC
See Also:
GNOME target: ---
GNOME version: 3.1/3.2



Description Chris Lahey 2003-03-02 21:15:46 UTC
No way to find out the filename of a .desktop file from nautilus.
Comment 1 Christian Neumair 2004-10-20 19:25:05 UTC
Nautilus 2.8 features a launcher property page, so it doesn't do any harm and
should be simple to display the filename of the desktop file on the first
property page instead of the Name attribute of the .desktop file.
Comment 2 Luis Villa 2005-01-02 16:51:41 UTC
What's the use case here? When do you need to find the name of the .desktop file?
Comment 3 Chris Lahey 2005-01-06 20:31:45 UTC
You need to find the name of the desktop file if You're going to access it using
the file system.  This is very important for developers at times.
Comment 4 Nelson Benitez 2005-08-20 18:54:02 UTC
I would like to have what Christian says in #1. It's a bit help to developers.
Apart is good to have a reference to real filename in property page because of
this situations:

 - A user has a nautilus open with a folder that has some launchers. User opens
same folder from gedit (gtkfilechooser) and he founds very *strange* that now it
has appeared some files ending in .desktop that nautilus didn't show.

 - User has some launchers in a tar.gz, he inspect it with file-roller and see
some .desktop files, after extracting he won't find those files.

 - A typical developer situation where in commandline you create a launcher from
another and edited one with vi, I went to nautilus to delete the original one,
but I could not distinct which was the original as have the same names and
property page does not show real filenames.

 In that situations it would be explanatory if you open property page of
suspicious file and see "Real name: ...", otherwise you will end up thinking
nautilus is hiding information and so you will loose trust on it ... :)
Comment 5 Michael Ekstrand 2007-01-19 18:58:52 UTC
I'll add a second to requesting some kind of solution to this.

Additionally, it would be nice to have a way to open the desktop file itself in a text editor.  Perhaps even an option to entirely disable Nautilus's special handling of desktop files temporarily (e.g., View->Show special files as normal).  This would allow me, as a developer, to manipulate the .desktop or .desktop.in files in my source tree as normal files to edit them, etc.
Comment 6 Paul Wellner Bou 2007-11-15 10:28:56 UTC
I just want to add here, that I really would like to see the file name while browsing the file system with nautilus. Disregarding the type of the file. I had a problem with the index.theme files. Nautilus recognizes them as desktop files. So I can't open them like other text files with a single click. And, as just said, I wish to see the filename: index.theme, and not the name of the theme there.
Comment 7 Dylan McCall 2009-05-28 14:12:50 UTC
This could be accomplished UI-wise by Nautilus displaying the literal name of a .desktop file when "Show Hidden Files" is enabled, and displaying its helpful name for it in the usual 'hidden files are hidden' mode.
Comment 8 Cosimo Cecchi 2009-05-28 14:32:41 UTC
*** Bug 572436 has been marked as a duplicate of this bug. ***
Comment 9 António Fernandes 2018-05-09 16:43:07 UTC
Thanks for taking the time to report this.
This particular bug has already been reported into our bug tracking system, but we are happy to tell you that the problem has already been fixed in the code repository.

*** This bug has been marked as a duplicate of bug 688632 ***