[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Review Request: When a .desktop file (app shortcut) is modified
From:       "David Faure" <faure () kde ! org>
Date:       2009-09-14 15:07:14
Message-ID: 20090914150714.16063.87397 () localhost
[Download RAW message or body]


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


[prev in list] [next in list] [prev in thread] [next in thread]