Please see this:
http://mail.gnome.org/archives/gtk-devel-list/2004-February/msg00256.html

*** Bug 143179 has been marked as a duplicate of this bug. ***

I should have pointed out that the mail in question contains a workaround.  This
would indeed be nice to have.

Asking people to create symlinks is not really a reasonable workaround,
especially since you can't do that from within the file chooser dialog. After
all bookmarks have been invented to make life easier for newbies.

IMHO the severity of this report should be changed from enhancement to major.

I also would love to see the user being able to rename any bookmark to whatever
she wants. Using symlink is a workaround for now and should work for geeks but
it's not a realistic option for all other users that we're aiming GNOME at.

Combined with the full path of the shortcut available as a tooltip 
(Bug #137503) the bookmark system could improve a lot.

*** Bug 159145 has been marked as a duplicate of this bug. ***

*** Bug 159996 has been marked as a duplicate of this bug. ***

Ok, dupe it is...  Importing the essence from 159996:

Bookmark naming should work for application-specific bookmarks too
(those added by gtk_file_chooser_add_shortcut_folder) and there should
be an API to set the name.

Updating version, OS, adding "I18N".

Any ideas how we could implement this in a backwards-compliant way for UNIX?
Since we currently have ~/.gtk-bookmarks which contains one URI per line, I'd
suggest one of these options:

1.)
create ~/.gtk-bookmarks-links/
on rename, create a link from ~/.gtk-bookmarks-links/somename to the target
destination and add the link URI to ~/.gtk-bookmarks, removing the original URI

pro: backward-compatible
con: link/hd clutter

2.)
change ~/.gtk-bookmarks format
add optional possibility to set a name for an URI, maybe through a separator
character (like file:///home/federico###My Home)

pro: no link/hd clutter
con: not backwards-compatible at all. Will break my bookmark-applet, for instance

3.)
moving completely to a new location, maybe using GKeyFile

pro: we can even put i18n info into the bookmarks, no link/hd clutter
con: neither backwards-compatible. Might create sync headache for
pseudo-backwards compatibility (syncing old bookmarks, but those have different
 UI names?!)

4.)
adding some new association file, line:name or such

pro: no link/hd clutter
con (see 3.))

If you change the format, just use a space for the separator.  Spaces are not
valid characters in a URI, so you shouldn't have any conflicts, and it'll make
it a lot easier to use normal UNIX tools on the file.

Created attachment 37050 [details] [review]
implement bookmark renaming

Here is a patch which implements bookmark renaming. To avoid compatibility
issues, I write a separate file, $HOME/.gtk-bookmark-labels, which contains
lines of uris and labels, separated by ' '. Only bookmarks which actually have
custom labels are  listed in that file, thus .gtk-bookmarks is still necessary.
The GtkFileSystem interface gets two new methods, 

gchar	*gtk_file_system_get_bookmark_label (GtkFileSystem     *file_system,
					     const GtkFilePath *path);
void	 gtk_file_system_set_bookmark_label (GtkFileSystem     *file_system,
					     const GtkFilePath *path,
					     const gchar       *label);

In the UI, renaming is realized via a context menu on the bookmarks list with
a "Rename..." item. Since single-item menus are a bit silly, I added a "Remove"
item as well.

Please do also allow to set labelled bookmarks from the application. Perhaps
gtk_file_chooser_shortcut_folder_set_label()?

Good point, I had forgotten about that. 

I also think we may want to ditch the idea of a new file, and just
change the format of .gtk-bookmarks. The file was clearly not meant or
documented as a public interface, and anybody using it right now is doing so 
his own risk.

One more think we may want to add to the file format is support for grouping
bookmarks, so that we can implement application-specific bookmarks later on.
Or we could switch to a file format that is more extensible than a mere text
file.

Wouldn't GConf be perfect for this?

I think we have already too many .files in ours $HOME

GTK+ doesn't use GConf (and it shouldn't).

Matthias: EEEK! GNOME-Panel uses it. Please don't change it. This will create
major headache.

Martin: GConf CAN in fact interact with GTK+ through xsettings. But for being
ready for a non-GConf environment, we have to add a disk-backed storing anyway.
Besides, syncing GConf and files on disk is evil, since GConf internally works
with other files on the HD as well.

Well, if gnome-panel uses private interfaces, it gets what it deserves.

It can easily be fixedi to work with the both formats.  Simply cut
off uris at the first space.

I can update the panel code before 2.10.0 to handle the old and the new formats.

I committed code to the panel so that it supports this new format.

*** Bug 170440 has been marked as a duplicate of this bug. ***

2005-03-22  Matthias Clasen  <mclasen@redhat.com>

	Implement bookmark renaming  (#136216, Sean Middleditch)
	
	* gtk/gtkfilesystem.h (struct _GtkFileSystemIface): Add 
	get_bookmark_label and set_bookmark_label vfuncs.

	* gtk/gtkfilesystem.h:
	* gtk/gtkfilesystem.c (gtk_file_system_set_bookmark_label): 
	(gtk_file_system_get_bookmark_label): Wrappers for the
	vfuncs.

	* gtk/gtk.symbols: Add new exported symbols.

	* gtk/gtkfilesystemunix.c (gtk_file_system_unix_set_bookmark_label): 
	(gtk_file_system_unix_get_bookmark_label): Implementations
	for the Unix backend.

	* gtk/gtkfilechooserdefault.c: Add a context menu to
	the bookmarks pane, and allow to rename bookmarks.