Having the following three items in one folder (e. g. the desktop)... - symlink to folder - link to location (URL) to folder - a regular folder ...can cause visual confusion because of the icons used: - symlink to folder --> folder icon with a little black and white arrow - a regular folder --> regular folder icon - link to location (URL) to folder --> SAME icon as a regular folder There is the following related issue: Especially on the desktop a "link to location" (which could also be shortly named "shortcut" to distinguish it from "symlink" and because it has the same functionality as a shortcut on the MS Windows operating system) makes more sense to me than having symlinks there. Reason: for example when clicking on a symlinked folder on the desktop the location bar shows the folder to be a subfolder of the desktop which can cause confusion. Suggested changes in the following three categories: 1) Naming - I know this causes much discussion but I still suggest it :) Rename "Link to location (URL)" to "Shortcut / Link to location (URL)" or similar 2) Icons * regular folder: no change * symlink: no change * shortcut: add an arrow as with a symlink icon but make it distinguishable somehow (by color and/or by form) and especially do not make it look like a regular folder 3) Drag and Drop context menu * currently when dropping a folder (or file) to desktop one has got three options in the appearing menu: - Copy here - Move here - Link here * I suggest to change it to this: - Copy here - Move here - Symlink here - Shortcut here In my opinion this makes it more transparent that on the Linux Desktop there are two types of links. If the goal would be to hide this fact, then "Link here" should default to "Shortcut here" and not to "Symlink here" for the desktop. But actually I would use both so I would like to see the extended menu.
Thanks for the report. This is not a Dolphin issue. The "Create New..." menu, that appears, e.g., in the context menus of Konqueror, Dolphin, and FolderView, is provided by kdelibs, and AFAIK, everyone can add additional items there by installing a Desktop file in the suitable location. So I'm not quite sure where to reassign this report. (In reply to comment #0) > 3) Drag and Drop context menu > * currently when dropping a folder (or file) to desktop one has got three > options in the appearing menu: > - Copy here > - Move here > - Link here Drag&drop is unrelated to the context menu. Please do not mix unrelated things in a single report. The drag&drop menu is provided by lib/konq in the kde-baseapps repository. > * I suggest to change it to this: > - Copy here > - Move here > - Symlink here > - Shortcut here A big -1 from my side. The average user will have no clue what "Symlink" and "Shortcut" means.
Thanks for all the hints. >> * I suggest to change it to this: >> - Copy here >> - Move here >> - Symlink here >> - Shortcut here > A big -1 from my side. The average user will have no clue what "Symlink" and "Shortcut" means. I think the symlinks concept is harder to grasp for the average user than a simple shortcut. So what do you think about setting "shortcut" (link to location) as default?
(In reply to comment #2) > I think the symlinks concept is harder to grasp for the average user than a > simple shortcut. So > what do you think about setting "shortcut" (link to location) as default? I think you mean a .desktop file which contains a "URL" line when you say "simple shortcut"? I'm asking because I've never seen the term "shortcut" in the context of links in the Linux/KDE world, and I'm not aware of any other kind of links (except symlinks and hard links). If that assumption is true, I fail to see why this is a simpler concept than a symlink. The .desktop file is a text file, which happens to be interpreted as a link by some applications, like Dolphin, but not by others (try to open it with KWrite, for example). What is simple to grasp about that? Accessing a symlink has the same effect as accessing the file directly, no matter how you access it. If we replace symlinks by .desktop files in the drag&drop menu, as you suggest, we would get a huge amount of complaints, because this will break the expectations of all users who have happily created symlinks in the past years. And BTW, I'm not aware of any complaint about the symlinks before this report. bugs.kde.org is not the best place to discuss such changes - few people read bug reports. If you have ideas for changing the behavior of KDE applications or libraries, you might want to start a discussion with other users at KDE Brainstorm: http://forum.kde.org/viewforum.php?f=83 If you believe that there is a usability problem and you know a way to improve it, you might also want to write to the kde-usabily list.
(In reply to comment #3) > (In reply to comment #2) > I think you mean a .desktop file which contains a "URL" line when you say > "simple shortcut"? I'm asking because I've never seen the term "shortcut" in > the context of links in the Linux/KDE world, and I'm not aware of any other > kind of links (except symlinks and hard links). You are right. In the "Create new" context menu the .desktop file is called "Link to location (URL)" and the symlink "Basic link to file or directory". > If that assumption is true, I fail to see why this is a simpler concept than > a symlink. The .desktop file is a text file, which happens to be interpreted > as a link by some applications, like Dolphin, but not by others (try to open > it with KWrite, for example). What is simple to grasp about that? True. > Accessing a symlink has the same effect as accessing the file directly, no > matter how you access it. > If we replace symlinks by .desktop files in the drag&drop menu, as you suggest, we would get a huge amount of complaints On the other hand, applications currently have (other) problems with symlinks, e. g. - https://bugs.kde.org/show_bug.cgi?id=318696 - or when a symlinked file on the desktop is opened and then the original file, the recent files menu will show both files as if they were two different files. Or when the symlink on the desktop is then removed, the recent files menu will point to nothing although the file still exists in its original location. As you suggested I will take the discussion to the usability list.
These two link modes with their different behavior cause issues. We should unify them and make that single mode as intelligent as possible. *** This bug has been marked as a duplicate of bug 249553 ***