Version: (using KDE Devel) Installed from: Compiled sources The icons' properties dialog doesn't allow you to change the icon for symlinks. Technically that's because there is no *.desktop file where this information could be saved (I think), but from a user's point-of-view this looks like a bug (it's common to have just symlinks on the desktop that point to applications, isn't it?).
Subject: Re: New: icons cannot be changed for symlinks On Sunday 19 October 2003 21:36, you wrote: > The icons' properties dialog doesn't allow you to change the icon for symlinks. Technically that's because there is no *.desktop file where this information could be saved (I think), but from a user's point-of-view this looks like a bug. Is this about symlinks to .desktop files? Or symlinks to binaries? > (it's common to have just symlinks on the desktop that point to applications, isn't it?) Well, it's more common to have .desktop links (created with "New / Link To Application") than raw symlinks, I think.
It's about symlinks to binaries, created by drag'n'drop the binary and choosing "Link here" (or so) from the popu menu.
Subject: Re: icons cannot be changed for symlinks On Sunday 19 October 2003 23:08, you wrote: > It's about symlinks to binaries, created by drag'n'drop the binary and choosing "Link here" (or so) from the popu menu. Obviously we can't set an icon for those - where would we store it? I would really prefer not to introduce new semantics (like storing this in the .directory of the desktop - which would be one more inconsistency when opening ~/Desktop in Konqueror, etc.) The only sensible solution I see, is to let "Link here" create a .desktop file instead of a symlink. Only for binaries, since for other files there's an icon from the mimetype. I don't like it when such automated behavior happens in the back of the user though, so this would mean renaming "Link here" to something more explanatory (but what? it's still about creating a link, just not the same kind... "Create link to application", like in the New submenu?) What do you think?
I'm not sure, but what about always creating a .desktop file and calling the menu item "Create a reference" or so (to avoid the technical term "link")? People who really need a symlink (why?) can still do that via Konqueror or shell. But as I said, I'm not sure :-)
I absolutely agree. The "link here" action should always create a .desktop file, and not only when dropping a binary, since e.g. one would also like to be able to change the icon for a specific document linked onto the desktop, rather to have for all e.g. .ods files the same OOO-calc icon. For the user, it's absolutely not clear why some icons on the desktop can be changed, but others can not. I recently ran into this problem when converting my fathers desktop from Win98 to KDE...
> The "link here" action should always create a .desktop file, and not only when dropping a binary, That sounds horrible. Of course it must stay possible to add pure symlinks to the desktop (drag and drop), expecially for files, I hate being domineered over like in Windows. What we need to satisfy all users might be an additional entry in the drag and drop menu: "create symlink" (those who want to use it know what this means) and "create desktop link".
I would opt for: 1) renaming "link here" to "create reference" (as Daniel suggested) 2) this "reference" would create both symlink and .desktop file associated with it On the other hand, deleting should delete symlink plus .desktop file with it. I think that introducing another action as Janet suggested is bad -- you would get for actions, have mercy :-) Janet, could you explain what is horrible in additional .desktop file. I see no real disadvantage of this solution, I am not GB maniac, but HDD is quite cheap, so I prefer modestly priced productivity over complex system which could save (?) 20 bytes per file. PS. Premature optimization :-D -- .desktop file could be created on-demand, for example when the user changed the icon. But I would opt against it, it is not worth the effort.
@Peter: do you agree on keeping this on dolphin bugs? Actually is dolphin which manage file icons, am I right?
@FiNeX: it's OK leaving the product to Dolphin, but I've set David Faure to CC as he was involved into the discussion.
Creating TWO items (a symlink and a desktop file) makes no sense to me. Surely you don't want to see two items in the directory view, and I don't want to introduce additional magic to hide one of them... I think what would make sense is to provide a 4th action in the drop popup to offer a "create reference" (with a status tip "this creates a desktop file" or something like that). This way you get the choice between a raw symlink and a desktop file where you can change the icon. This is a case where there is no "better for everyone" solution, both have advantages.... Meanwhile when setting up a KDE desktop for a recent-convert end-user, I strongly suggest to create desktop files to launch applications :-)
SVN commit 1016454 by dfaure: FEATURE: in the "RMB / Create New" submenu, add "Basic link to file or directory", so people can create symlinks. Hopefully the "basic" indicates clearly enough that the icon can't be changed and that it's only for local files or dirs, no urls. CCBUG: 66248, 197840 To implement this cleanly I refactored the knewmenu code to use a strategy per type of entry, to get rid of the previous spaghetti code. Not that I don't like spaghetti in general, but well... M +33 -4 Templates/CMakeLists.txt A Templates/linkPath.desktop M +287 -168 knewmenu.cpp M +1 -10 knewmenu.h M +3 -2 knewmenu_p.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1016454
@David: is it a graphical interface for "ln -s" ? Really good!!! :-)
Yes it is - but Drag-n-Drop + choosing "Link" was already a gui for ln -s, that's exactly what this report is unhappy about ;-) My commit allows to create both "desktop-file links" and "basic links" from the 'Create New' menu, but it doesn't address this actual report which is about the Copy/Move/Link popup during drag-n-drop. I'm still not sure what to do about that one without making things confusing though. "Copy/Move/Link/Basic Link" is a lot of link-related options in a menu where 90% of the users use Copy or Move 95% of the time...
what do you think about asking to user if he want a "basic symlink (sl command) where icons cannot be changed" and "desktop file link where icons can be changed" with a checkbox popup window, just after the drag and drop and if the user have chosen link in the menu "copy/move/link here", as you said this menu is used 96% for copy and move, so that link question-popup affect only 4% of users or time and shouldn't be so boring :-), furthermore I think the default should be a user-newby-oriented choice so I think the .desktop files should be the default
Resetting assignee to default as per bug #305719
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.