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 andresbajotierra at gmail.com
Mon Sep 14 15:16:30 BST 2009


On Mon, Sep 14, 2009 at 6:46 AM, David Faure <faure at kde.org> wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1390/#review2343
> -----------------------------------------------------------
>
>
> I'm surprised, because the idea was that the local desktop file would be merged with the global one.
> (If it does not, then we should just copy the whole file first....)
>
> So IMHO instead of copying one field (and leaving all others as un-specified, so the problem
> isn't really fixed overall), we should find out if the global-local merging is supposed to
> work or not, in this particular case, and if not, copy the whole file.
>
>

So far in my analysis I have discovered that:
1) the properties dialog is launched, loading the system-wide .desktop entries
2) when some entry is modified:
 a) it detects that it can't write on thje system-wide one, so it sets
the new URL to the local filename
 b) it now saves the properties it has loaded to the new file (as it
would do if the URL hasn't changed)  (the class
DesktopFilePropsPlugin~ is involved, I don't remember the name right
now)
 c) as the icon didn't changed, saving the icon entry is not necesary;
 but as the new file doesn't contain all the entries from the global
one, the icon is empty. Therefore I provided this patch

I guess step b) should be modified to raw-copy the global .desktop to
its new local location; instead of only saving the fields that changed
under a new filename.

In any case, this is a minor issue. Plasma has moved towards using
FolderView widgets to show desktop:/ or other icon files; and the
icon-widget method is going "deprecated".
I don't know if there is any other case on which this patch (or the
whole fix) could be useful

Thanks for reviewing it.
Darío

> - 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
>>
>>
>
>




More information about the kde-core-devel mailing list