GNOME Bugzilla – Bug 43311
"Places" sidebar should support D'n'D
Last modified: 2007-07-01 21:54:21 UTC
Seems that a lot of browsers these days are putting their bookmarks in a sidebar. Since Nautilus has a sidebar, this might be something to consider. Also this makes for a nice interface for editing the bookmarks, ala Mozilla. ------- Additional Comments From darin@bentspoon.com 2000-09-27 15:42:02 ---- Good idea. ------- Additional Comments From eli@eazel.com 2000-10-16 19:48:48 ---- Batch-assigning QA ownership of remaining bugs to eli@eazel.com ------- Additional Comments From don@eazel.com 2000-12-18 19:26:32 ---- Darn right this is a good interface idea in Mozilla! ;) What this bug needs is some scope to this feature, i.e. how bookmarks will appear, behave, be implemented, etc. in the sidebar. ------- Additional Comments From sullivan@eazel.com 2001-03-09 17:32:11 ---- We'll need some sort of grand bookmark design someday, which could consider the suggestions in this bug. ------- Additional Comments From j.f.benckhuijsen@home.nl 2001-07-19 14:39:32 ---- On my disk, my dir's are stored by subject. Maybe it would be nice to allow bookmarks to be stored on a per directory basis, just like the notes, so i can easily have access to the bookmarks associated with the data in the folder. ------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 20:40 -------
I think this is a good idea, however I feel that this should be one way or the other. Either this is in the menubar or the sidebar. Having it both ways would be redundant. Also with the current implementation of the sidebar, this would add more clutter, but hopefully i can convince darin to implement my idea in bug 74821, I can't help plugging my own bugs :) )
*** Bug 164637 has been marked as a duplicate of this bug. ***
I'd like to add those suggestions (from bug 164637) I would like a "favorites" panel where I could add my favorites folders /files by drag and dropping them from right panel or by editing them directly (user @protocol://server:port/path[/path][/file]) These favorites (folders only) should be visible when using the file selector dialog in any Gnome app
Nautilus 2.11 includes such a sidebar. It doesn't yet support D'n'D, though.
Wishlist: * ability to remove a place by dragging it off of the menu * ability to add a place by dragging it onto the menu * ability to move/copy a file/directory if its is dragged onto a folder on the menu * ability to drag and drop to reorder the menu * right click menu for each place - right click a folder get the options to rename/delete, right click a cd you get the options from Computer which allow you to copy the cd, eject it, etc. * single click opens a place instead of double click * 24x24 icons * at least one more px on the left margin of each icon, 2-4 more on the right, possible one more px added to vertical spacing * default font size looks good! * all removable media and network places go above the divider line by default, all file:/// vfs urls go below Opinions on these, especially as to their higgyness? Thanks, --Rob Caskey
Created attachment 49025 [details] [review] adds spacing, bumps up icon size, changes menu type to single select this is a diff against nautilus-2.11.3 that I made for my personal use but thought someone else might find it useful. Default icon size goes up to 32, places are selected with a single click regardless of click policy, and some cosmetic padding is added. BTW, after playing around with it a bit, I realize that icons should probably scale to be as small as 16px or as large as 32, but I don't have the ability to implement this, sorry. Thoughts? --Rob
Thanks for your efforts Rob! I think your patch isn't very useful, though, except for its single-click bits: The spacing stuff has to be sorted out for the file chooser and the sidebar and we need a consistent solution before randomly changing one of them. The icon size hack isn't really good either, since it doesn't ensure consistency with GtkIconSize changes. Bug 167107 handles that. Maybe you could resubmit the single-clicks part cvs diff -up'ed?
*** Bug 312097 has been marked as a duplicate of this bug. ***
From comment 5: * ability to remove a place by dragging it off of the menu * ability to add a place by dragging it onto the menu I'm a bit confused what you mean by "dragging it onto/off the menu"...you mean the places sidebar, right? I wonder where the user should move a place to remove it from the menu.
Into the trash, at best ;-) Seriously, I think this would be overkill and it has its own problems. Dragging folders into the places sidebar to make bookmars would be nice, though. The problem is the following: those entries in the sidebar are technically bookmarks, but they look like folders. Compare the places sidebar to the tree sidebar, it'S nerly impossible to make out the difference without knowing which is supposed to do what. This means that people will expect to use the places sidebar like the tree view: - beeing able to copy files/folders to the "bookmarks" using d&d - delete/rename using the context menu - eject removable media ... Right now d&d is not implemented for the places sidebar in any way. Dragging TO the sidebar is probably save to implement (both to make bookmarks and to use the existing bookmarks as drop targets) but dragging FROM the sidebar is more complicated because it's not clear what a user wants if he moves the bookmark "Documents" to the trash for example. Does he want to delete the bookmark? Delete the folder? The tree sidebar doesn't allow for something like that, dragging to it is possible but dragging from it isn't, which prevents the more destructive actions. If it is decided that the places bar entries are not to be used like the tree sidebar (using as drop targets, allowing context menu actions like "eject media") I propose to change the icons to somthing more bookmark-like to make it clear that those are not folders.
For me all this code should be implemented in a GTK+ widget. Most of the code/concept is copy/past from the gtkfilechooser. So I think (but i'm far from an expert) that something like GtkShortcuts should be coded in GTK+ and used as it in filechooser and nautilus... and maybe in more GTK+ applications if needed. This way we are sure the sidebar and filechooser are concistent. For the user both are the same, he expects to have the same look and feel with nautilus and filechooser. If one can do DnD the other should too. etc. Thats how I see it, but I may be completly wrong ?
Claessens: I disagree with you here, because we do handle some part of DND differently from the file chooser (cf. the middle-drag, which is Nautilus specific). Writing extra API for that would simply be overhead, considering that this is just a plain GtkTreeView.
Created attachment 51751 [details] [review] Proposed patch The attached patch allows users to drop files to the sidebar, either for copying/moving them to the folders in the sidebar, or for adding them to it. If you hover builtin bookmarks and volumes (above sep.), only copying/moving is allowed. This patch also implements middle-click dragging.
Updating bug information.
*** Bug 315026 has been marked as a duplicate of this bug. ***
*** Bug 318150 has been marked as a duplicate of this bug. ***
*** Bug 312836 has been marked as a duplicate of this bug. ***
played a bit with last patch and nautilus-2.13.3. Some things i've noticed by using the patch not read it yet: - when Drag a file with middle button and drop it on a buildin bookmark and select "cancel" it copies the file and don't cancel. - drop a folder on free space on the personnal bookmarks it doesn't add the folder to bookmarks like in GtkFileChooser. Would be great if the patch get fixed and commited, that's definitively something I want for 2.14 :-)
Created attachment 56107 [details] [review] Updated patch Attaching the updated patch Christian posted on the list.
Comment on attachment 56107 [details] [review] Updated patch Review from Alex: Drag motion over empty area at bottom doesn't allow you to create a new bookmark. Would be nice if it handled text/uri-list too, not only NAUTILUS_ICON_DND_GNOME_ICON_LIST_TYPE. As drops from non-nautilus are that type. +static unsigned int +get_bookmark_index_at_path (GtkTreeView *tree_view, + GtkTreePath *bookmark_path) This looks fragile. Why not put the index in the store instead? +static void +drag_motion_callback (GtkTreeView *tree_view, This can use pos and action undefined when setting the status. It leaks path. It shouldn't continue to run if (!sidebar->drag_data_received). But it should probably call gdk_drag_status() in drag_data_received_callback. + current_event = gtk_get_current_event (); + if (current_event == NULL || current_event->type != GDK_DROP_START) { Why is this event type check needed? It looks kind of weird.
*** Bug 324449 has been marked as a duplicate of this bug. ***
*** Bug 324840 has been marked as a duplicate of this bug. ***
Ok, it's implemented in 2.13.4/90. I ported the D'n'D and context menu code from the filechooser (to be as consistent as possible) and added the bits from Manny's patch to enable file transfers via the sidebar icons. The only missing bit is that it's not possible to rearrange the bookmarks via D'n'D like in the file chooser, otherwise it's pretty smooth. If you spot bugs with it, please file them as separate bugs.