Review Request 106771: Make sure KPropertiesDialog inherits the 'Categories' property when creating a new desktop file from an existing one

[Dawit Alemayehu]

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

(Updated Feb. 12, 2013, 12:41 a.m.)


Review request for kdelibs and David Faure.


Changes
-------

Updated the patch to copy the contents of the original desktop file before updating the fields that were modified. 


In the process I found that local desktop files are created in different locations depending on what you used to edit existing desktop files:

- If I modify a desktop entry from the KDE menu editor, the resulting .desktop file gets saved 
  under ~/.local/share/applications/kde4-<app-name>.desktop

- If I modify the same desktop file by clicking on the "Edit" button after selecting the application in the 
  'File Associations' dialog, then the resulting file is saved under ~/.local/share/applications/kde4/<app-name>.desktop.

Also, if the one of the above desktop files exist, they will be modified regardless the method used above. This leads me to believe that those file being saved to different locations was intentional. Is that right ?


Description
-------

The attached patch make sure the Categories properties is inherited when a new local dekstop file is created from an existing one. It fixes the bug mentioned in bug# 286717.


This addresses bug 286717.
    http://bugs.kde.org/show_bug.cgi?id=286717


Diffs (updated)
-----

  kio/kfile/kpropertiesdialog.cpp 7b52912 

Diff: http://git.reviewboard.kde.org/r/106771/diff/


Testing
-------


Thanks,

Dawit Alemayehu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20130212/ab7cfe8f/attachment.htm>