Problem with XDG TryExec, how to force updating menu

[Matthew Brush]

On 12-11-26 04:03 PM, jupiter wrote:
> Hi,
>
> I am running XFCE 4 on CentOS 6.2. I have an issue when a Linux
> package desktop application contains a TryExec statement which does
> not update menu when the  If the binary path is present and when it is
> executable according to the XDG spec.
>
> The package has two desktop applications in /usr/share/applications,
> request.desktop and response.desktop. the response.desktop has the
> statement "TryExec=/usr/local/bin/update.sh", but that script is not
> available until the application in request.desktop is called. It seems
> that the menu is not updating after the
> "TryExec=/usr/local/bin/update.sh" is available and therefore the
> response application could not see on the menu.
>

I doubt it sits there constantly polling the TryExec path, but rather 
I'd guess it uses file monitoring on the desktop entry itself (or the 
whole applications directory) to detect changes which triggers a 
reload/recheck (which would explain why "touch"ing it causes an update). 
I didn't look at the source, so it's just a guess, but it seems the most 
sane way to do it.

> The only thing I could make the response item on menu is run "touch
> /usr/share/applications/response.desktop" which triggering the menu
> update. It is ugly and it is not workable.
>
> Are there any commands / utilities can be used to force updating menu?
>

You could delete the TryExec line from the response.desktop one so 
there's no check performed and it's always in the menu (the spec says 
it's not required). Another way would be to replace the request.desktop 
Exec command with a custom script that runs the original program and 
then "touch"es the response.desktop.

Out of curiosity, what is the package with this weird desktop entry 
inter-dependency that is creating and deleting files in /usr/local/bin?

Cheers,
Matthew Brush