And in an ideal world, dragging and dropping stuff onto an "unmounted" bookmark should simply automount it for me (and request credentials if required), therefore fixing bug #524405.

I have had a short discussion with Cosimo Cecchi on IRC about this. The current behavior (can't drop stuff into bookmarks) is _intentional_. The reason is that with the 2.32 sidebar, DnD'ing a directory into the places sidebar could mean both 'make a bookmark' or 'copy into a bookmark', and it was difficult to properly disambiguate them. (A 1 pixel high dark line is _not_ the proper way to do it.)

I agree that the current solution is too restrictive.

A viable solution would be to add a dummy row, on DnD'ing a directory, so that only directories dropped ONTO the dummy row would become bookmarks.

I have a partially working patch that implements this, but I'll wait after 3.0 to propose it -- especially because it's far from finished, and I don't have the time right now to finish it up.

Of course, the design can, and should, be further discussed.

Yes, your alternate solutions make sense.

I might also add the following logic:
- when multiple items are selected, nautilus can safely assume that we want to do a move/copy operation, not create multiple bookmarks. So be it files or folders, that would work in all cases.
- when a single file (instead of a single directory) is dragged, we can assume it's a move/copy operation too

The dummy row that appears when dragging a single directory could have some sort of darkened area with text saying "Drop here to bookmark".

(In reply to comment #3)
> Yes, your alternate solutions make sense.
> 
> I might also add the following logic:
> - when multiple items are selected, nautilus can safely assume that we want to
> do a move/copy operation, not create multiple bookmarks. So be it files or
> folders, that would work in all cases.
> - when a single file (instead of a single directory) is dragged, we can assume
> it's a move/copy operation too

I'll make sure to integrate your suggestions. Thanks!

> 
> The dummy row that appears when dragging a single directory could have some
> sort of darkened area with text saying "Drop here to bookmark".

Yes, that's what it currently looks like.

Sorry to bump this after so long, but nautilus 3 is out and the feature has not been implemented. Is there any progress on it? I think its a basic feature that should really be included by default but isnt.

I think the solution for this is quite simple, actually.

When dragging multiple files to the bookmarks area, assume this is a move/copy.

When dragging a single file, move/copy.

When dragging a folder, the action depends on where the user drops. As a user drags the folder over the list of bookmarks, a line in between bookmarks indicates the folder will be added to the bookmark list. If they drag over a bookmarked folder, that bookmark is highlighted to indicate it will be copied/moved into that folder.

That's pretty standard behavior for drag/drop into a list of folders, really.

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

In fact, nautilus already does this! If you drag a file onto anything under "Computer" in the left pane, it highlights the folder it will be dropped into. And if you drag a folder into the bookmarks area, a solid black line shows up indicating where the new folder will be on the bookmarks list. Seems like it would be pretty straightforward to make the bookmarks list handle both drag/drop INTO a folder, and dragging new bookmarks onto the list.

I agree with samh. I cant understand why such a basic feature is lacking. The current procedure for moving a file to a bookmarked folder is way longer than it needs to be/should be.

Hear!  Hear!  This is a regression in my opinion.  The way it used to work was much better than the way it now doesn't work.  There isn't much reason to have a bookmark if you can't drag n drop to it.

Rob

Sorry for the lack of updates. The patch I was working on was never finished; adding temporary entries to the sidebar's filtered TreeModel proved not to be super-trivial. Add a severe lack of time on my part, and what you'll obtain is a stalled bug report.

Anyway, I'll hopefully update my patch during the weekend and report back.

Created attachment 200014 [details]
Nautilus bookmarks with copy/move and add boomark operations mockup.

Instead having a small black line, why not let the lower icons slide a bit down when you are between two in order to make a small gap for dropping the item between those. Could be even done with a semitransparent preview of the dragged object in the bookmarks.

When you are on a icon and not between two it just gets highlighted like the ones under "Computer" and the cursor changes accordingly.

This makes those two operations more visually distinguishable.

Just adding my voice saying that it's pretty silly that I can now no longer drop files into my bookmarked folders. How it worked before was fine.

Please fix this, it is a serious regression from v2.

If you thought it was a problem why not experiment with a fix before changing anything. Just removing functionality will just create much annoyance for your users.

Created attachment 201930 [details]
Music, Pictures, Video folders not shown

The documents and downloads folders are shown, but not the other default folders.

A related problem is that some of the default folders under 'Computer' i.e. Music, Pictures, Videos don't appear on the left when browsing for files via the browser, see attached screenshot for what I mean.

Another thing to note regarding the idea that dropping in between the folders puts a bookmark there, and dropping on a folder puts the files in the folder is that Mac OS (at least 10.4, Tiger) has this behavior, and Apple is the recognized leader in user friendly GUI design.  We should reconsider our views on this issue, if only because a lot of folk also use OS X and expect things to work similarly.

Thanks,

Rob

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

Created attachment 202449 [details] [review]
[RFC] unfinished, unpolished, buggy patch

Please see the attached RFC patch. It is unfinished (it only displays a `dummy' item when dragging stuff to the bookmarks section), unpolished, and spits gtk criticals here and there. The dummy jumps here and there while dragging stuff over the bookmarks (I have to come up with a saner compute_drop_distance() I guess), which is not really elegant, nor desirable. A smooth fade animation would be preferable, but I don't think it's feasible with a GtkTreeView.

I warmly welcome comments and suggestions.

Cheers,

Review of attachment 202449 [details] [review]:

I haven't actually tried this, so please take my comments with a grain of salt as a first drive-by review.
It's probably not really possible to do any fancy animations here due to the nature of GtkTreeView anyway :/

::: src/nautilus-places-sidebar.c
@@ +1092,3 @@
+
+	model = gtk_tree_view_get_model (sidebar->tree_view);
+	gtk_tree_model_foreach (model, remove_dummy_foreach_func, sidebar);

We don't expect to have more than one of these dummy rows at the same time, right?
So I think it's better to save the dummy row as a temporary GtkTreeRowReference instead of going trough the whole model on every motion callback.

@@ +1121,3 @@
+	icon_size = nautilus_get_icon_size_for_stock_size (GTK_ICON_SIZE_MENU);
+	icon_info = nautilus_icon_info_lookup (icon, icon_size);
+	pixbuf = nautilus_icon_info_get_pixbuf_at_size (icon_info, icon_size);

We do the same thing (pixbuf from GIcon) in add_place(). Perhaps we could factor this out into a separate function?

@@ +1195,3 @@
 			    -1);
 
+	is_heading = FALSE;

This snippet is a bit confusing; should be something like;

is_heading = (place_type == PLACES_HEADING);
if (is_heading &&
    section_type != SECTION_COMPUTER &&
    section_type != SECTION_COMPUTER)
  return FALSE;

@@ +1596,3 @@
 	    tree_pos == GTK_TREE_VIEW_DROP_AFTER) {
+
+		g_assert_not_reached ();

Why?

(In reply to comment #21)
> Review of attachment 202449 [details] [review]:
> 
> I haven't actually tried this, so please take my comments with a grain of salt
> as a first drive-by review.

Thanks Cosimo. :-)

> So I think it's better to save the dummy row as a temporary GtkTreeRowReference
> instead of going trough the whole model on every motion callback.

I had tried with storing a GtkTreeViewPath, but the path got out-of-sync with respect to the underlying model while adding/removing the dummies, so I picked the safest approach. I didn't know anything like RowReference existed, I'll switch to it.

> @@ +1121,3 @@
> +    icon_size = nautilus_get_icon_size_for_stock_size (GTK_ICON_SIZE_MENU);
> +    icon_info = nautilus_icon_info_lookup (icon, icon_size);
> +    pixbuf = nautilus_icon_info_get_pixbuf_at_size (icon_info, icon_size);
> 
> We do the same thing (pixbuf from GIcon) in add_place(). Perhaps we could
> factor this out into a separate function?

Most definitely.

> +    is_heading = FALSE;
> 
> This snippet is a bit confusing; should be something like;
> 
> is_heading = (place_type == PLACES_HEADING);
> if (is_heading &&
>     section_type != SECTION_COMPUTER &&
>     section_type != SECTION_COMPUTER)
>   return FALSE;

Yeah, a lot cleaner.

> @@ +1596,3 @@
>          tree_pos == GTK_TREE_VIEW_DROP_AFTER) {
> +
> +        g_assert_not_reached ();
> 
> Why?

Left-over debug code; compute_drop_position here only returns the INTO_OR_{BEFORE, AFTER} variants.

As for the general approach: if there's no way to make the dummy stop jumping around, I think I'll switch to the much easier (and comparatively pleasant) option of just one fixed row, just below the Bookmarks heading, as the only possible bookmark target, with a big "DROP HERE PLEASE" label. It's far from optimal, but it's better than nothing.

Any movement on this?

Please forgive my ignorance and impatience but I don't understand why this is taking so long?

Surely the Bookmarks folders can/ should just function like the Computer folders below them do? Since you can drag files into the Computer folders, why not just make the Bookmarks folders function in the same way? What am I missing?

I recognise that may not be particularly helpful but this is really pretty basic functionality that has always worked fine up until ubuntu 11.10. Why can't whatever change broke this basic function be reverted back to how it was?

I agree with Josef, I appreciate your work, but could you please fix this or at least update some info, if anybody is still interested in solving this bug? Ubuntu 12.04 is almost here and other distributions will benefit from it, too.

Finishing the patch would certainly help to speed up things.

trying out the attached patch, I get

nautilus-places-sidebar.c: In function ‘add_dummy’:
nautilus-places-sidebar.c:1175:34: error: ‘NautilusPlacesSidebar’ has no member named ‘filter_model’

any clues?

Created attachment 213487 [details] [review]
fixed patch for 3.4.x compatibility - GTK_TREE_MODEL_ITER removed

thx to Cosimo Cecchi for pointing me into right direction.

Since this seems as yet unresolved I'd like to put forward the following proposal:

Problem to solve:
There are two candidate actions for a drag&drop operation to the bookmarks: Adding a Bookmark and Copying/Moving to a bookmark. (side-note: keyboard modifiers should be used to differentiate between copying and moving)

Current state:
This was "resolved" by eliminating the "Copying/Moving" action and leaving only "Adding a Bookmark". Thus eliminating the usefulness of bookmarks together with the problem.

Observation:
Of the two, "Copying/Moving to a bookmark" is a frequently used action, while "Adding a Bookmark" is performed only only very seldom or only during UI customization. Thus "Copying/Moving to a bookmark" should be easy to do while "Adding a Bookmark" does not need to be as easy and fast to do.

Proposal:

* Drag&Drop to a Bookmark should perform "Copy/Move to a bookmark"
* Drag&Drop to a new "Add Bookmark" Icon at the bottom of the bookmark list should add a new Bookmark at the bottom of the bookmark list.
* Rearranging bookmarks should be done by dragging around bookmarks that are already there.

I second Bernhard's proposal!  We need this fixed.

Thanks,

Rob

I third Bernhard's proposal!

(whilst also having a confused look on my face wondering why we can't just go back to exactly how it worked before before a non-problem was "fixed" thus creating the problem we all have now)

+1

+1

This problem has seriously broken my workflow. I used to be able to have lots of bookmarked folders in the left and categorize files easily from an incoming directory. Yes, occasionally dragging to the sidebar would create another boookmark (or bunches of bookmarks), but it doesn't take much practice to always get it right. With the new sidebar, I can only change the content that is being viewed. So I have to open a new nautilus window, click on the bookmark (the only thing it is now good for) and then drag from the first window to the second. Alternatively, I have to open a dual-pane window and remember to have the other side selected before clicking on the bookmark. Not a good situation at all, unless it were still 1993. I'd prefer the old behavior simply be restored as it worked fine.

I now implemented a solution similar to Bernhard's proposal to git master.
I didn't add the proposed "Add bookmark" DnD target row, as it wouldn't really play nicely with the case of the sidebar being vertically scrollable, and is not really do-able without nasty hacks in the code.