typo in my previous report : please read "Icecat.desktop" instead of "Thunar.desktop"

On my Desktop also.

Happens on my Gentoo laptop too, xfce desktop 4.7.4. I even tried to set the "GenericName" variable or to add a "Name[fr]" (my locale is fr_BE.UTF-8) variable to the desktop file while editing it with Mousepad but it doesn't change anything.

Did the definition of "Blocker" change recently? There are still two (with this one being one of them) left, but yesterday xfdesktop-4.8 was released with only minor cosmetic changes …

Comment 5 Jannis Pohlmann 2011-01-17 18:13:53 CET

I don't know who marked this a blocker. It really isn't. Blockers are bugs that cause data loss and make things crash for everyone.

Created attachment 3371 
Launcher on desktop problem.

On my Arch Linux after upgrading from 4.6 to 4.8 problem exist. See attach (sorry for size :/), in thunar window looks fine but on desktop bad.

Same here , Arch Linux upgrading to 4.8 , had same screenshot in mind ...
Please any feedback what's going on ? Users Desktop is like the business card of a graphical desktop to me, and it's broken, pretty sad.
Icons that are loaded and work via .desktop are global references only.
Those images that are linked to my home folder are not drawn on desktop , but drawn in the properties window. The syntax of the .desktop files is 100 % correct as even the examples from xfce.org don't work.

Created attachment 3378 
xfdesktop bug

Comment 10 Jannis Pohlmann 2011-01-18 20:07:38 CET

I'm fixing it right now.

Comment 11 Jannis Pohlmann 2011-01-18 20:49:16 CET

Fix in master and the xfce-4.8 branch. There's another issue that I consider important to fix before a bugfix release makes sense. Once that's tackled I will release xfdesktop 4.8.1.

commit bef2dd0cdec38b914558fa3a8261660cabccfaef
Author: Jannis Pohlmann <jannis@xfce.org>
Date:   Tue Jan 18 20:42:47 2011 +0100

    Use Name field as display name of desktop files (bug #6896).
    
    To implement this in a somewhat clean way, the function
    thunar_g_file_query_key_file() was copied over as
    xfdesktop_file_utils_query_key_file(). Another method
    xfdesktop_file_utils_get_display_name() was added to determine the
    correct display name to use for a given file and file info.
    
    XfdesktopRegularFileIcon was altered to include a private variable
    display_name in which the cached display name is stored.

Thanks a lot, Jannis. That was fast.

Can't wait till 4.81.8 :D .

Congrats on 4.8 BTW. Keep up that good work, guys!

(In reply to comment #12)
> Can't wait till 4.81.8 :D .

Meh... s/4.81.8/4.8.1/g    :facepalm:

(In reply to comment #11)
> Fix in master and the xfce-4.8 branch. There's another issue that I consider
> important to fix before a bugfix release makes sense. Once that's tackled I
> will release xfdesktop 4.8.1.
> 
> commit bef2dd0cdec38b914558fa3a8261660cabccfaef
> Author: Jannis Pohlmann <jannis@xfce.org>
> Date:   Tue Jan 18 20:42:47 2011 +0100
> 
>     Use Name field as display name of desktop files (bug #6896).
> 
>     To implement this in a somewhat clean way, the function
>     thunar_g_file_query_key_file() was copied over as
>     xfdesktop_file_utils_query_key_file(). Another method
>     xfdesktop_file_utils_get_display_name() was added to determine the
>     correct display name to use for a given file and file info.
> 
>     XfdesktopRegularFileIcon was altered to include a private variable
>     display_name in which the cached display name is stored.

I experienced the same issue:
- Apps on the desktop present.
- Executable
- ISSUE: Name: <>.desktop (e.g. Opera.desktop)
- ISSUE: Icon: Text symbol

I tried the fix patch from:

http://git.xfce.org/xfce/xfdesktop/commit/id=34f869dbb5a6ee41f1b18a2f3b2db0be516be09d

The name issue has been rectified, but the application icon is still shown as if the app was a text file. Same setup worked a treat with 4.6.2. Can someone maybe confirm the icon image prob?

Comment 15 Jannis Pohlmann 2011-01-25 03:11:26 CET

*** Bug 7183 has been marked as a duplicate of this bug. ***

Comment 16 Jannis Pohlmann 2011-01-26 23:22:49 CET

*** Bug 7190 has been marked as a duplicate of this bug. ***