Red Hat Bugzilla – Bug 137477
non-writable desktop icons
Last modified: 2007-11-30 17:10:53 EST
I hope I do a decent enough job of explaining this problem...
When I drag a menu item from the Main Menu to the desktop, I get a
little icon that shows that the .desktop file I just created in my
~/Desktop directory is read-only. This is irritating from a
user-interface point of fiew, because the user doesn't think of this
icon as a file, they think of it soley as an application launcher. It
seems to me that the action of dragging a menu item from the main menu
should automatically chmod the file to 600.
Additionally, the behavior is inconsistent if I drag the icon to the
panel before dragging it to the desktop. For example, if I drag an
item from the Main Menu to the panel and release it, it appears in the
panel. Then if I click and drag that icon from the panel to the
desktop, the permissions on the file will be 700.
Shouldn't the file permissions work the same way if I'm dragging from
the menu to the desktop or from the panel to the desktop?
Sounds odd alright
Nautilus does a simple copy of the applications:///... file on the
desktop. Upstream the permission info field for the vfolder gnome-vfs
method is disabled, in our packages permission is 666 (because of our
vfolder patches). I guess it's read only to not allow editing.
I doubt we can do much about it in control-center. Reassigning to
nautilus (in the lack of any better solution I guess the handling of
the applications: uris could be special cased).
I think the new implementation of menus on gnome-panel head fixes
this. Still if we want to do a work around for fc3/RHEL4 it should
probably be in nautilus.
Otherwise I guess we could verify and mark this upstream.
Verified with cvs version of gnome.