Comment 2 for bug 133566

Revision history for this message
Dylan McCall (dylanmccall) wrote :

Krychek, that does not solve the problem. The issue I am discussing is the Places which /can not/ be edited, and how they correspond with the user-created bookmarks.

There are currently three Places lists, each with a different selection of built-in Places that could not be easily edited by the user, and user-created bookmarks which are stored in the same central location. People thus create bookmarks to link to locations not linked to by the built in places. The problem arises here, because while those bookmarks may be fine in one list, they are redundant in another. Most notably, this commonly caused a redundancy problem in the main menu's Places list, which ultimately led to Bug #122602.

Nautilus should automatically list mounted file systems in Places, and maybe special locations like network://. However, specific locations like Desktop should always be saved with user-defined bookmarks.
To fix the obvious loss here (it's good having Desktop and File System linked to in Places out of the box), there can be some user-controllable bookmarks set by default. Specifically: Desktop, / and Home. (Possibly the automatically created home subfolders, too, such as Documents, Downloads and Public).

The ultimate goal here would be that every places list, be it the one in the GTKFileChooser widget, the main menu or Nautilus, has the exact same items. They already show the exact same bookmarks, so integrating that automatically generated chunk of the menu should not be too difficult. Just takes some imagination.
One thought would be a file that lists every item that should be in the Places menu. Then, every time a program wants a Places menu, it reads from that file instead of duplicating code.