The items on the Folder widget used as desktop containment are often as shortcuts to the original item. When the user drops a folder or a file onto the desktop there are three options: Copy, Move, Link. When Link is chosen, a symlink is created (which looks the same as a regular folder). Currently, when this is left-clicked, dolphin opens and it looks as if the folder is a subdirectory of ~/Desktop. I would find it more useful if the click would open the folder in its original location.
That's how symlinks work. There's also some patch to indicate them by a "link" icon and italic text, though.
I know what you mean. But in case of the desktop a presumably common use case leads to problems when symlinks are treated like everywhere else: USE CASE: Create a symlink on the desktop to a place in the file system to get back to it quickly. Now lets assume the symlinked folder contains pdf files. If I open one of the pdf files from the symlinked folder and the same from the original location (which are semantically identical in the above use case) then there are two different items in the Recent File list of okular (or LibreOffice; the only exception there is kwrite and kate). An alternative would be to extend the drop menu (Copy, Move, Link) with another option like "Shortcut" which behaves like "Link to location..." and creates a .desktop file.
I just talked to Jens and Aleix and they proposed to add Eike to the discussion. If we don't change the default desktop symlink open behaviour what about adding the new item "Shortcut" to the drop menu which might be less invasive? I need some input by people who actually use the Folder View. (Kai, do you use it?)
In fact, I don't. However, if your application's recent document implementation treats the very same file differently based on the fact one is a symlink while the other isn't, it's broken. Note that Eike is the maintainer of Folder View so he is assigned to this bug report automatically. It's his decision to make but I don't see a bug on our side here.
> if your application's recent document implementation treats the very same file differently based on the fact one is a symlink while the other isn't, it's broken. Ah, ok. Is this a common consenus? For example LibreOffice behaves like this. Should I open a bug report there? > I don't see a bug on our side here. Sorry. Yes, I changed it to "wishlist". For me it is more of a usability issue with Folder View than an actual bug.
I read the initial report, but Kai was faster in replying (and I agree with him), that's why I didn't speak up. Resolving symlinks and giving the target URL to an application would be really wrong and break the concept of symlinks, sorry.
@Eike: thanks for the reply. I would be interested in your opinion on these three related questions I stated above: 1) Do you think that non-KDE applications whose recent document implementation treats the very same file differently based on the fact one is a symlink while the other isn't should be notified that this is wrong (like in LibreOffice)? 2) In my experience the desktop is primarily used as a kind of launcher to open files or directories; not something one wants to work with directly, What do you think about this? 3) If 2) is true, symlinks might be the wrong concept to use to create shortcuts on the desktop. So, for example what about extending the drop menu (Copy, Move, Link) with another option like "Shortcut" which behaves like "Link to location..." which creates a .desktop file? This option could be shown only for the desktop/FolderView.
> 1) Do you think that non-KDE applications whose recent document implementation treats the very same file differently based on the fact one is a symlink while the other isn't should be notified that this is wrong (like in LibreOffice)? I don't know. From the app developer perspective, it might be legitimate to say "they're different paths". Symlinks are rare and people who make them usually know what they're doing. > 2) In my experience the desktop is primarily used as a kind of launcher to open files or directories; not something one wants to work with directly, What do you think about this? Yes, but if you deliberately make a symlink on your desktop that's probably what you want to "work with directly". If you don't want a symlink, you can just keep the file right on your desktop or make a copy. If you make a symlink you get a symlink. > 3) If 2) is true, symlinks might be the wrong concept to use to create shortcuts on the desktop. So, for example what about extending the drop menu (Copy, Move, Link) with another option like "Shortcut" which behaves like "Link to location..." which creates a .desktop file? This option could be shown only for the desktop/FolderView. I'm not opposed, feel free to work on that.
> Yes, but if you deliberately make a symlink on your desktop that's probably what you want to "work with directly". Currently, the menu item of the drop menu is called "Link" and there is no other choice. I wouldn't call that "deliberate". ;-) I guess, most of the symlinks on people's desktops are there because there is no other (obvious) choice (or did I miss it?). In my opinion the user needs some more guidance here. For example, naming the item actually "Symlink" instead of generically "Link". > > 3) If 2) is true, symlinks might be the wrong concept to use to create shortcuts on the desktop. So, for example what about extending the drop menu (Copy, Move, Link) with another option like "Shortcut" which behaves like "Link to location..." which creates a .desktop file? This option could be shown only for the desktop/FolderView. > I'm not opposed, feel free to work on that. Thanks for the feedback. I'll do that.