alacarte doesn't honor changed .desktop files

How would you suggest I fix this? Even if I read every .desktop file that Alacarte had changed and updated the Exec that wouldn't be right, people change the Exec lines on purpose (to add nonXgl or aoss, for example). There is no way to automatically know when this should happen.

save the original entry/entries from the desktop file together with the changed file. Maybe in the case of an error, check the saved entry with the one from the desktop file to see, if they changed. In my use case, the Exec entry saved by alacarte and the original entry (not yet saved) by alacarte are not changed and you can safely update from the desktop file. In other cases, the user could be asked.

I'm afraid I'm going to have to reject this bug on the basis that the existing behaviour is well known, more predictable and is even documented in the GNOME Desktop System Administrators Guide in the online documentation:

"Since user menu files take precedence over the system menu file, it will completely replace the system menu unless it explicitly merges the system menu."

It's a feature, not a bug. :-)

reopening, even if's documented, it doesn't make sense. there is a proposed fix. documenting omissions isn't equivalent to fixing.

- Define error
- Show me how alacarte is supposed to know when nautilus/gnome-panel fails to launch a .desktop file

Perhaps this should be reassigned to the panel? The original .desktop file is still in /usr/share/applications so it can look there.

Travis Watkins schrieb:
> - Define error

it fails for the user with no visual feedback.

> - Show me how alacarte is supposed to know when nautilus/gnome-panel fails to launch a .desktop file

as described in the comment on 2006-09-25

> Perhaps this should be reassigned to the panel? The original .desktop
> file is still in /usr/share/applications so it can look there.

yes, but not the old original version. therefore the suggestion in the
comment above to keep the original data when alacarte changes it.

The only way to reliably fix this is to fix the freedesktop specification. The underlying problem is that there is no clean way that meets the specification to override the NoDisplay attribute of the .desktop file without copying the whole file to the user's applications directory. Matthias's suggestion would be to have arbitrary parts of the system (like the panel, or any other menu consumer for that matter) to change the .desktop files in the user's overrides, which IMHO is simply not appropriate. Consider the use case that the user has manually copied .desktop files from the system ones to ensure they don't get updated with the system's ones. There is no way according to the specification to determine that.

In other words, we can't automatically change something the user may have set manually.

I would suggest one of the following solutions:

1. add in an attribute to the Filename tag of the .menu file format to allow overriding of attributes in the .desktop file. That way, the .desktop file can stay in the system directory, with any overrides (like, the "NoDisplay" config) existing in the user's .menu file.

Something like this:

        <Menu>
                <Name>Accessories</Name>
                <Include>
                        <Filename NoDisplay="False">nautilus.desktop</Filename>
                </Include>
        </Menu>

2. add in an element to the .desktop specification which allows inheriting from the system one, like this:

[Desktop Entry]
Inherit=true
NoDisplay=false

This has similar benefits.

Both of these solutions, however, will take a change to the freedesktop specification.

Rejecting for now. If someone has a patch I might consider it otherwise this needs specification work at freedesktop.