.desktop files can be used to create links to other files and folders. However, in dolphin, when you enable grouped view and sort by Type, those .desktop files are placed in the "desktop configuration file" group rather than the group with the target file type. If .desktop file links are meant to be mostly transparent to the user, as I assume they are, then this is a bug since it drastically reduces the transparency of such links. If not then this is an enhancement request and can be re-categorized as such. Steps to reproduce: 1. Open dolphin 2. Right-click on a blank space 3. Select "Create new" 4. Click "Link to Location (URL)" 5. In "File name" field, put "root" (no quotes, you can choose something else if you prefer) 6. In the "Enter link to location (URL)" field, put "/" (no quotes, you can choose something else if you prefer) 7. Click the menu wrench 8. Select "sort by" 9. Click "Type" 10. Click the menu wrench again 11. Click "Show in groups" Expected results: You have a "root" (or whatever you chose) entry in the "folder" group. Actual results: You have a "root" (or whatever you chose) entry in the "desktop configuration file" group.
Resetting assignee to default as per bug #305719
I would indeed consider this an enhancement request rather than a bug, because the mime type of a .desktop file is "desktop configuration file". I'm not quite sure if .desktop files are indeed supposed to be as transparent as symlinks, which is what you suggest if I understand you correctly.
As far as I know you can't have a symlink to a kio slave, which means .desktop files are the only way to put a link to a remote location in a folder. So I think this argues for making them as transparent as symlinks.
But then this kind of transparency needs to be implemented in KFileItem, which is the class that tells us about the mime type.
I agree with Frank. For a local path, use a symlink. For a remote path or a link, Dolphin really doesn't have any way to introspect the .desktop file to see where it leads, and because of the near-infinite possibilities, that sort of isn't reasonably implementable. As always, patches are welcomed, and if you or anyone else comes up with a way to do this, we will definitely consider it.