GNOME Bugzilla – Bug 73773
renaming items via 'edit launcher' slightly broken
Last modified: 2009-08-15 18:40:50 UTC
Repro: Load applications:/// Right-mouseclick on Accessories Select Rename Enter any text and submit. Result: There is no "Accessories" in this folder. Perhaps it was moved or deleted?
This should be linked to 72715 as connected with non-functioning menu editor
*** Bug 73839 has been marked as a duplicate of this bug. ***
Fixed in CVS.
Nope. This is not working for me with a full platform build of today's code.
Does the rename show up after a manual refresh? If not, is an error dialog displayed?
No error is shown and reloading doesn't show a new name. Closing the window and reopening applications:/// also does not show the new name. When I initially select Rename from the folder's context menu, the log output shows: (nautilus:11902): GnomeUI-CRITICAL **: file gnome-icon-item.c: line 129 (send_focus_event): assertion `GTK_WIDGET_HAS_FOCUS (widget) == in' failed
Closing and reopening does update the text- so I assume this is a duplicate of some part of bug 81670, george, alex?
OK, after some reflection, we're not going to hold the release over this. I'd like to see it in ASAP, of course, and if it is a small fix, I'll see that it is acceptable to release team, but given that one can delete and add things instead of renaming, I'm having a hard time seeing this as a release blocker.
The renaming doesn't work for me at all. My Applications menu still shows "untitled folder". Closing and reponing applications:/// does not help for me. Also, attempting to add a launcher causes Nautilus to hang. 100% repeatable. The launcher does get created. Repro: Open applications:/// Open the Games folder Right-mouseclick -> Add Launcher Fill in launcher name, command and select an icon. Submit Result: The open Nautilus window stops refreshing. I have to restart Nautilus to get rid of the window. The launcher does get created.
Argh. 'Works' here with this morning's code, that's all I can say on that count. George, Alex: any clues?
Luis, How are you installing your builds? Red Carpet? If so, do you have Gnome1 installed as well? I am building from cvs using v-b-s.
RC, with gnome1.
Please see new bug 84841 - renaming now wipes entry among other problems - major reversion
*** Bug 85299 has been marked as a duplicate of this bug. ***
*** Bug 87464 has been marked as a duplicate of this bug. ***
Fixed with vfolder rewrite, which can be found on the gnome-vfs-2-0-vfolder-rewrite branch of gnome-vfs.
What date of cvs was this fixed in - not fixed as of sunday
Reopening; Alex, this isn't fixed in this morning's CVS. What I did: *right-click on the 'Open Office' icon in applications:///, select 'rename' *type in OO.o as the new name *killall gnome-panel, hit reload in nautilus (just to be sure.) *now have no icon in panel menu and two icons, both named Open Office, in applications:///.
This is a nautilus bug. It is checking that the file has a URI starting with file:// before doing the .desktop rename, otherwise it falls back to regular file rename. Patch attached below...
Created attachment 10311 [details] [review] Allow non-file:// URI when renaming .desktop files
Still not fixed with a fresh checkout of eel/nautilus - worse if anything Current ststus rename of launchers works rename of folders either works or totally obliterates folder (not recoverable) - every trace of my favorites folder has now gone including vfolder in /etc New apps dont get registered in menus reload of nautilus does not update display
Have you updated to latest gnome-vfs from the gnome-2-0-vfolder-rewrite branch?
So, with latest build (from some point this afternoon) I get a rename. Yay! Unfortunately, when I close applications: and then reopen I get a double icon in applications:. On the plus side, when I restart gnome-panel it is also changed there, and there isn't a duplicate.
Alex - all my comments are based on gnome-vfs rewrite, eel and nautilus as of am 7/8/2002 Luis - I am finding massive inconsistency - sometimes it seems to work - sometimes it doesn't or wipes out stuff
OK, this now works for me in all cases except when I rename using the 'edit launcher' option in the right click menu. It seems to always work otherwise, and even in that case it is reflected in the panel menu- just not in applications:// until I reload the view.
Apparently this is the fault now of bug 81670; marking dup. *** This bug has been marked as a duplicate of 81670 ***
I am getting a segmentation fault from nautilus (sometimes the panel) whenever I edit the folder launcher
Mike, Can you please attach a stack strace for both the panel and nautilus? To avoid bogus stacks, it is best to attach gdb to the process before you edit the launcher.
This should be fixed with latest CVS.
This is not fixed in a build from this morning. Looks like (AFAICT) 81670 still doesn't work.
For example, testing 73770 works fine in panel, and works fine after a reload of applications:. So it's still not updating correctly.
On my system with latest cvs - no different from pre-gnome2 ie: rename of individual launchers works rename of folders either doesnt work at all or crashes nautilus for default folders removes them copy and paste of folders works, but of course they cant be renamed There seems to be a permissions problem somewhere (note whenever I attach gdb to nautilus, nautilus hangs until I kill gdb)
Luis, I am unable to duplicate what you are seeing at all. Please reopen this if it is still happening after a fresh install. Mike, folder renaming is covered by another bug, and since this seems to be the only issue you mention, I'm closing this one.
Using gnome-vfs2-2.0.1.0.200208151304-0.snap.ximian.1, I get the following behaviour: * in Nautilus, renaming a folder by pressing F2 results in the folder disappearing * renaming a launcher by right-clicking and pressing Edit Launcher achieves nothing * renaming a launcher by pressing F2 results in the launcher changing name in the nautilus window, but restarting the panel still shows the old name.
I suspect that your snapshots are too old. The code to fix some of this stuff went in late last night. Please try with latest source or wait for next round of snaps. I'll mark NEEDINFO in the meantime.
Alex - what bug is renming in if not this one
Sorry, it is part of bug 89616.
I'm closing this; I've tested everything Mike listed as an issue and it works now in public snaps. Mike, if you could confirm I'd really appreciate it.