"xdg-desktop-menu install" requires a logout the first time

[Thomas Leonard]

Binary package hint: xdg-utils

When installing a new application for the first time, the new menu entry doesn't appear immediately. You have to log out and log back in again. However, installing further applications works fine.

To reproduce (on a clean Gutsy system):

1. Create a new user:

$ sudo adduser bob

2. Log in as "bob"

3. Install the sample .desktop file:

  $ xdg-desktop-menu install test-test.desktop

4. Notice that no entry appears in the Applications->Accessories menu.

5. Log out and log back in again.

6. Menu item is now visible.

From this point on, any further programs added show up immediately.

As an alternative to logging out, running alacarte and then immediately quitting it also makes the new entry appear.

[Thomas Leonard (talex5)]

Confirming that this bug also affects Hardy.

[Thomas Leonard (talex5)]

Are you able to reproduce this? Do you need more information?

[Thomas Leonard (talex5)]

Ping?

[Jan Niklas Hasse (jhasse)]

Hi there,

We (Autopackage developers) just experienced the same bug when installing locally. Would be great if this could be fixed.

[Andreas Mohr (andi)]

Is this bug permission-caused?

I just experienced a missing desktop menu icon on 8.04.1 after having run xdg-desktop-menu via root on a non-live session tree, and when re-running the command as root on the actual running session (live CD creation project!) it did add the icon to the desktop.

Investigation showed that the .desktop file had 0400 permissions only, with no warning message whatsoever output by xdg-desktop-menu upon installation that the .desktop file would be inaccessible by mere mortals!!

IOW:
- non-live session: add as root; no user session available there, thus no hook there invoked which could have added the icon with the help of root powers.
- ensuing live session: NO icon visible
- live session: add as root, icon becomes visible! (updated in user session)
- live session: add as user, error message: "no permission to read ....desktop" or some such to that effect

This is severe usability bug #4 or so which I experienced using xdg-utils (IOW a wee bit _way_ too many) in a short time, time for a rather verbose bug report into this particular direction... (will do)
The entire xdg-utils handling feels waaaay too raw and unpolished for such a central package, especially for rather non-savvy OEMs.
(quick quizzz: what's the best way to turn people away from Linux desktop deployment plans? Yeah, you guessed right...)

Thanks!

[Roy Dennington (roy-semichem)]

We use the xdg-utils to install our 3rd party app as part of a dpkg install. As root, the App does NOT get registered, it does NOT appear on the menu, and the mimetypes are NOT functioning. I have also tried using the xdg-utils manually, without success. The corresponding files appear in both /usr/share and /usr/local/share. The permissions are correct.

[Roy Dennington (roy-semichem)]

With the latest release, everything is working. As root, I was able to get my App integrated with the xdg-utils. Here are a few safety tips:
[1] The TryExec entry MUST be in the path. Adjusting the PATH in .bashrc is TOO LATE. I had to modify .profile (actually, we drop an init into /etc/profile.d).
[2] Mimetype icons for gnome are NOT located in hicolor. We had to repeat xdg-icon-resource for the gnome theme to get correct icons in Nautilus.

[Thomas Leonard (talex5)]

This bug still occurs on Jaunty, following the steps in the original report.