Bug 66248 - icons cannot be changed for symlinks
Summary: icons cannot be changed for symlinks
Status: CONFIRMED
Alias: None
Product: dolphin
Classification: Applications
Component: general (show other bugs)
Version: 16.12.2
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-10-19 21:36 UTC by Daniel Naber
Modified: 2021-03-09 02:18 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Naber 2003-10-19 21:36:52 UTC
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?).
Comment 1 David Faure 2003-10-19 22:57:54 UTC
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.

Comment 2 Daniel Naber 2003-10-19 23:08:39 UTC
It's about symlinks to binaries, created by drag'n'drop the binary and choosing "Link here" (or so) from the popu menu. 
Comment 3 David Faure 2003-10-19 23:21:29 UTC
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?

Comment 4 Daniel Naber 2003-10-21 00:47:55 UTC
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 :-)
Comment 5 Martin Koller 2006-01-08 17:51:10 UTC
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...
Comment 6 Janet 2006-03-27 03:19:36 UTC
> 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".
Comment 7 Maciej Pilichowski 2007-05-11 13:23:52 UTC
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.
Comment 8 FiNeX 2008-12-10 01:19:01 UTC
@Peter: do you agree on keeping this on dolphin bugs? Actually is dolphin which manage file icons, am I right?
Comment 9 Peter Penz 2008-12-10 08:16:06 UTC
@FiNeX: it's OK leaving the product to Dolphin, but I've set David Faure to CC as he was involved into the discussion.
Comment 10 David Faure 2009-02-12 13:58:58 UTC
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 :-)
Comment 11 David Faure 2009-08-27 22:35:41 UTC
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
Comment 12 FiNeX 2009-08-28 01:15:21 UTC
@David: is it a graphical interface for "ln -s" ? Really good!!! :-)
Comment 13 David Faure 2009-08-28 02:13:41 UTC
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...
Comment 14 pier andre 2011-04-10 17:42:36 UTC
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
Comment 15 Jeroen van Meeuwen (Kolab Systems) 2012-08-24 16:18:38 UTC
Resetting assignee to default as per bug #305719
Comment 16 Justin Zobel 2021-03-09 02:18:44 UTC
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.