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

[Darío Andrés]

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

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