GNOME Bugzilla – Bug 367273
gnome-menus doesn't send notification for new .desktop files
Last modified: 2007-05-25 18:23:29 UTC
Please describe the problem: As per: https://launchpad.net/distros/ubuntu/+source/gnome-menus/+bug/64264 "If you add/edit menus in Edgy, the menu shown in alacarte isn't updated until you reload alacarte and the actual gnome menu isn't updated until either a package upgrade updates it or you kill gnome-panel." (reported by Chris Lord on 2006-10-06) Steps to reproduce: 1. Start the alacarte menu editor 2. Copy a menu item to another menu (with drag and drop) 3. Attempt to view the results in either alacarte or the panel menu 4. Restart alacarte to see the results 5. Restart the panel to show the copy was indeed successful Actual results: The copy succeeds but is not applied to running menu consumers. Expected results: The copy should cause a notify event to update the menus in the running applications. Does this happen every time? Yes Other information: I have made a patch to fix this problem (and another problem that only surfaced after fixing this). It is attached at the above-mentioned launchpad url.
Created attachment 75636 [details] [review] This patch fixes the passing on of .desktop directory notifications
Please review this patch. It's just a simple one-liner
Doesn't look right to me. Take the simple case of a .desktop file being deleted. We only want to invoke the monitors if something has actually changed in our view of the world, so we only want to invoke monitors if cached_dir_remove_entry() returns TRUE Also marking this bug as NEEDINFO, as there isn't enough info for me to figure out the bug myself - e.g. what exactly is alacarte doing when you copy an item, what does the gnome-menus verbose log show etc. ?
Alacarte is just making a copy of the .desktop using a new filename and adding an <Include> for it. I do it this way so you can independently edit each .desktop instead of wondering why changing one changes both. Also, it probably doesn't help that I cannot trigger this bug. So far no one else I've asked has been able to give me a method to reproduce it unless they copy an item with spaces in the name (which is a separate bug I'm just going to avoid by making up a file name).
There is a better fix to the "spaces in filename" problem at: http://librarian.launchpad.net/4940208/gnome-menus-2.16.1-fix_.desktop_notifications_uri_handling.patch It's the way you're doing the url encoding for gnomevfs calls that's causing the problem.
Created attachment 88786 [details] [review] Fix for gnomevfs file change notification
This is a patch changing a patch that isn't upstream... You should just fix the downstream patch.
If it's only a bug happening with spaces and this is only happening because downstream is using a patch for the file monitoring, then it's not a GNOME bug.
Indeed, sorry about that. That probably explains why I didn't attach that patch here before. :-) So the bug Travis mentions must be a separate issue then, or is that referring to the bug introduced downstream too?
I'll let Travis reply :-)
I can drag and drop things without spaces and they show up in their new location immediately in alacarte and in the menu. This is probably just a bug in ubuntu's patch.