Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nemo option to show REAL filename for .desktop files #2456

Open
lucypol opened this issue Jul 23, 2020 · 21 comments
Open

Nemo option to show REAL filename for .desktop files #2456

lucypol opened this issue Jul 23, 2020 · 21 comments

Comments

@lucypol
Copy link

lucypol commented Jul 23, 2020

 * Nemo version (nemo --version)
Nemo 4.6.4

 * Is issue with desktop or windowed nemo?
Windowed

 * Distribution - (Mint 17.2, Arch, Fedora 25, etc...)
Mint 20

 * 32 or 64 bit
64-bit

Issue
Not showing the real filename for .desktop files

Steps to reproduce
list files in /usr/share/applications/

Expected behaviour
Showing real filename

Other information
I would like an option to show the real filename and not this hide the real name like Windows
This is partly why we left Windows, so we can see the real information, not what is spoon fed to us by deception

Having this hidden results in errors, I nearly deleted what I thought was duplicate entries for applications when they were different files but the display showed them as duplicate files

At the very least give me an option to display the REAL FILENAME

With the real filename hidden you're causing PROBLEMS, especially for new users who are likely to delete what they see as duplicate files

For example, "Update manager" shows two duplicate .desktop files in Nemo, but when you go to the command line, they are in fact different filenames. Krita application, shows a dozen of different .desktop files and Nemo shows them as duplicates

This is Linux, NOT WINDOWS.

Regardless of what the Freedesktop spec says, I want an option to OVERRIDE it so I see the real filenames.

@lucypol lucypol changed the title Nemo to show REAL filename for .desktop files Nemo option to show REAL filename for .desktop files Jul 23, 2020
@Jeremy7701
Copy link
Contributor

Also a problem in nemo 4.6.4 on LMDE4
How long has this .desktop thing been a "feature" of some Linux distros?
Note that you can find .desktop files scattered in multiple directories:-
/etc/alternatives/
/etc/xdg/
/etc/xdg/autostart/
/home/user/.config/autostart/
/home/user/.kde/share/apps/
/home/user/.local/share/applications/
/usr/lib/gnome-settings-daemon-3.0/gtk-modules/
/usr/lib/nvidia/current/
/usr/share/app-install/desktop/
/usr/share/applications/ etc....
even
/usr/share/gnome/applications/nemo.desktop

@lucypol
Copy link
Author

lucypol commented Jul 23, 2020

The problem is not the existence of .desktop files, it is with how it is displaying them, I want to see the actual filename, not the label from the contents inside it, that's Windows decepticon shit right there.

Nemo is a FILE MANAGER, I want to see the filename, not some fudgecake

Nemo is NOT showing the real filename, that is what the issue is, I don't care if Freedesktop org wants to display the contents as the label, I want the real filename displayed

I open NEMO as a filemanager to manage files, if I wanted cake I would go to a cakeshop

I want to see blahblah.desktop, blahblah-something.desktop NOT blahblah and blahblah

blahblah.desktop is the FILENAME, blahblah is the contents, if I want to see the contents I open it in the text viewer

@lucypol
Copy link
Author

lucypol commented Jul 23, 2020

Also a problem in nemo 4.6.4 on LMDE4
How long has this .desktop thing been a "feature" of some Linux distros?
Note that you can find .desktop files scattered in multiple directories:-
/etc/alternatives/
/etc/xdg/
/etc/xdg/autostart/
/home/user/.config/autostart/
/home/user/.kde/share/apps/
/home/user/.local/share/applications/
/usr/lib/gnome-settings-daemon-3.0/gtk-modules/
/usr/lib/nvidia/current/
/usr/share/app-install/desktop/
/usr/share/applications/ etc....
even
/usr/share/gnome/applications/nemo.desktop

You missunderstand the issue, try reading it again

@Jeremy7701
Copy link
Contributor

Apologies for reading /usr/share/applications/ as the only directory at fault - I'd like an option in nemo that allows all .desktop files to be shown, regardless of which directory they are in.
One complication is that the real filename often bears little resemblance to the application name that gets launched.

@lucypol
Copy link
Author

lucypol commented Jul 23, 2020

Apologies for reading /usr/share/applications/ as the only directory at fault - I'd like an option in nemo that allows all .desktop files to be shown, regardless of which directory they are in.
One complication is that the real filename often bears little resemblance to the application name that gets launched.

Seriously, STFU, it's people like you that are bad for Linux, bog off. you didn't even understand the issue to begin with, I'm surprised you made it past the installer. Do us a favour, fuck off from Github and stop chirping in with your lame dumb shit, fuck off back to Windows or buy a Mac, dumbass.

It has nothing to do with what directory they are in, it has nothing to do with the existence of the .desktop file, it is with the fact it is not showing the filename and it is showing the contents data as the name

They can still follow freedesktop org standards (good or bad) and still allow overriding of them so we all get what we want

When I open a file manager, I want to see filenames, if this crap keeps going on like this I have no further use for the filemanager and have to resort to using a terminal solution

The danger with the current display is you risk deleting THE WRONG FILE as it shows them ALL THE SAME since they have the same label in the contents but different filenames. This is the most idiotic stupid display decision I have ever seen.

THIS IS NOT WINDOWS, REPEAT 100 times, THIS IS NOT WINDOWS

When I seen the real filename, it was clear as day what each file was for, with the current display, it was just a waste of time and error prone.

You can have your dumbed down and confusing shit if you want, allow me to override it.

@Jeremy7701
Copy link
Contributor

Dear lucypol,
Thanks for the lovely off-topic rant about you hate Windows...[me too].

Whilst nemo doesn't show what you want, there is a limited workround:-
The last post in https://askubuntu.com/questions/17220/can-nautilus-display-a-desktop-file-by-its-real-name indicates one possibility (and yes it does work in nemo):-

sudo ln -s /usr /USR
If we browse in nemo /usr/share/applications, the nemo display will be unchanged.
If we browse in nemo /USR/share/applications, nemo will display the real file-names of the .desktop files.

@AlexFolland
Copy link

AlexFolland commented Dec 28, 2021

This issue is still relevant. I'm posting this because it is more than 1 year later, to clarify the status.

Hiding the file names is counterproductive and makes working with these files difficult and confusing.

@MarkJeronimus
Copy link

MarkJeronimus commented May 6, 2022

I agree that this should be implemented as i got really confused when my text editor showed a different filename than the one I started editing. It's counterproductive, and I lost about 5 minutes reading this thread and not finding a solution.

@Jeremy7701
Copy link
Contributor

There's a long-running (but interesting) discussion on the security implications of desktop files at https://unix.stackexchange.com/questions/373239/what-is-the-advantage-of-desktop-files-without-executable-bit-set

@bernd-wechner
Copy link

I'm with the crew that want Nemo to be a file manager and not a deception engineer. Show me the files in a directory please, not some disguise. Please.

@Jeremy7701
Copy link
Contributor

When was the last time you needed to view or access a desktop file by name?
The answer for nearly everyone would be never.
So why allow a general purpose file manager - such as nemo provide easy access?

@AlexFolland
Copy link

AlexFolland commented Dec 13, 2023

On the other hand, why would a file manager try to hide something about a file? It's okay for these *.desktop files to be hidden by things like launcher menus, launcher widgets, and desktop background icon systems, but a file manager must always display the files verbatim. I have personally been annoyed by Nemo when trying to browse my *.desktop files and see their correct file names, only to have my file manager betray me and hide the names, with no option to prevent it from doing so.

It's obvious the majority of users want their file manager to actually do its job and manage the files, and only one singular person in this ticket wants to leave the file manager as some kind of botched launcher tool that's so GNOME-like that it doesn't even have an option to disable this functionality.

@bernd-wechner
Copy link

When was the last time you needed to view or access a desktop file by name?
The answer for nearly everyone would be never.
So why allow a general purpose file manager - such as nemo provide easy access?

Methinks you miss the point entirely. It is definitely NOT the job of the file manager to doctor the view of files.

How often: rarely, indeed. And when you do, suddenly look at one (like for example on a piece of portable software just unzipped which includes one, then suddenly, confusion - as Nemo oddly displays two - or more - 'files' with the same name).

You have the burden of justification the wrong way around here methinks. It is disappointing to say the least to find a decent and laudable file manager doctoring the displayed names of any files. A right royal bother to a great many people on earth was Windows decisive effort to look more Mac like a long time ago and by default hide file extensions on their explorer. Works for grandma, but frustrates a fairly large body of users, whose first move on getting a new PC or account on one after running explorer and thinking WTF? is to turn that off.

@Jeremy7701
Copy link
Contributor

Perhaps a nemo setting for desktop files (off by default) would be acceptable - provided you could persuade the nemo team of its utility?
It could be buried with the other minor settings via gsettings.

@AlexFolland
Copy link

provided you could persuade the nemo team of its utility

Multiple people have come here to figure out why files aren't represented properly by Nemo in a particular directory, and a ton of rationale has been given in this thread already.

buried

Displaying files as they are in the system verbatim should be the default for the file manager. If it is even not disabled by default, obviously the setting should be exposed in the settings GUI in a prominent place, since this anti-feature of hiding correct file names breaks the expectation of the job of a file manager.

@MarkJeronimus
Copy link

MarkJeronimus commented Dec 13, 2023

Obviously they just want to cater the 'general population' instead of us hardcore users. Just like Windows Explorer also doctors both files and directories (e.g. translating c:\Users to whatever display language you have configured).

I've never used Explorer, even before Microsoft started these shenanigans, and as long as I used Windows and had Total Commander, I used that. NB: also don't even think about suggesting any Linux *Commander (e.g. Double Commander or Krusader), because they're all bulky, slow, and/or are missing simple features like thumbnailing.

@AlexFolland
Copy link

To cater to the "general population", the correct file names should be shown. The "general population" expects the file manager to display the files. There is no reason to navigate to that directory specifically in a file manager if not looking for the files with their correct file names.

@Jeremy7701
Copy link
Contributor

This argument is getting painfully repetitive.
Either the Mint/LMDE team will accept this as an important priority (initially raised as an issue back in 2020) or they won't.

@AlexFolland
Copy link

The duration that an issue can be reproduced does not affect the inconvenience the issue presents. It's been almost 2 years since I first commented here that the ticket is still relevant, and the ticket is still just as relevant. Please stop trying to convolute the thread in order to diminish the legitimacy of the need for a fix. If you're bothered by the ticket, you can unsubscribe.

@leigh123linux
Copy link
Contributor

If you're bothered by the ticket, you can unsubscribe.

I have unsubscribed due to lack of interest in the niche non-issue.

@Jeremy7701
Copy link
Contributor

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants