Review Request: When a .desktop file (app shortcut) is modified and "copied"(re-written) from a system-wide to a user location; the icon should be saved, even when it was not modified

[David Faure]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1390/#review2351
-----------------------------------------------------------


Ah, I missed the fact that this was in the context of (old) plasma icons. In such a case, I suspect the lack of "merging with the global desktop file" is normal.

However in general (K menu entries, for instance), the merging happens, and for that reason, duplicating the Icon field into the local file isn't such a great idea (the next time icons are renamed you end up with "?" for all those apps)

Tricky problem, but as you say, probably not important anymore.
Apart from those old-style icons on the desktop, I don't see a case where one would see a global .desktop file, and edit it (into a local one), and yet without desktop-file-merging being used during display...?

- David


On 2009-08-23 20:38:10, Darío Andrés wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1390/
> -----------------------------------------------------------
> 
> (Updated 2009-08-23 20:38:10)
> 
> 
> Review request for kdelibs.
> 
> 
> Summary
> -------
> 
> Mh, I don't really know if this is a big deal but I wanted to try to fix it. (I'm not even sure if the workflow that derived in bug 164472 is a valid one just to try to fix this)
> 
> The file properties dialog only saves the icon field in the .desktop files; if the icon was indeed changed.
> However, there is one more case in which saving the icon field will be needed: when modifying an icon/desktop that represents a system-wide .desktop file; changing some attribute. This will cause the .desktop to be rewritten to a local place (~/.local/share/applications/kde4); but the DesktopPlugin of the file properties will not write the Icon field;  causing this new icons to have an unknown/invalid/empty icon.
> 
> The patch checks if the path changed from the start upto the save moment; and will force saving the Icon field if the file was also a .desktop one
> 
> 
> This addresses bug 164472.
>     https://bugs.kde.org/show_bug.cgi?id=164472
> 
> 
> Diffs
> -----
> 
>   svn://anonsvn.kde.org/home/kde/trunk/KDE/kdelibs/kio/kfile/kpropertiesdialog.cpp 1013119 
> 
> Diff: http://reviewboard.kde.org/r/1390/diff
> 
> 
> Testing
> -------
> 
> Primary testing: it worked; and fixed bug 164472. Editing a local desktop file without changing the icon didn't applied the icon field again.
> 
> I see a trailing space. If I commit this I'm going to remove it.
> 
> 
> Thanks,
> 
> Darío
> 
>