After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 785619 - Can't dnd to the pathbar
Can't dnd to the pathbar
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: Path Bar
3.24.x
Other Linux
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 786269 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2017-07-31 09:35 UTC by Sebastien Bacher
Modified: 2017-09-10 01:30 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
pathbar: Restore ability to act as drop target (1.37 KB, patch)
2017-08-14 10:53 UTC, António Fernandes
none Details | Review
pathbar: Restore ability to act as drop target (6.10 KB, patch)
2017-08-14 13:56 UTC, António Fernandes
none Details | Review
Revert "pathbar: Remove dnd handling" (8.97 KB, patch)
2017-08-17 10:43 UTC, António Fernandes
committed Details | Review
pathbar: Remove drag-source handling (4.11 KB, patch)
2017-08-17 10:44 UTC, António Fernandes
committed Details | Review

Description Sebastien Bacher 2017-07-31 09:35:30 UTC
Using nautilus 3.24, dnd of a file to the pathbar (titlebar) is not doing anything, it used to be possible to move files to a directory that way with older versions of nautilus.
Comment 1 Carlos Soriano 2017-08-07 14:10:02 UTC

*** This bug has been marked as a duplicate of bug 776663 ***
Comment 2 Carlos Soriano 2017-08-07 14:37:04 UTC
The background is bug 776663
Comment 3 Ernestas Kulik 2017-08-14 09:48:02 UTC
*** Bug 786269 has been marked as a duplicate of this bug. ***
Comment 4 Mario Wenzel 2017-08-14 09:59:48 UTC
So the "broken" use cases I gathered from the related issues:

* A folder from the Path Bar can no longer be dropped into a "save-file" dialogue to have that folder open within the dialogue

* Files and folders can no longer be dragged onto the Path Bar to move or copy them there. This includes the parent folder and there is no other way to reach the parent folder when dragging files. This is especially egregious since the user is automatically thrown into a folder while dragging when they hover over a folder for too long.

As I understand it, this was done so that the nautilus window can be moved more easily when the path bar is long.

Currently I can drag the nautilus window by the Back/Forward-navigation buttons, the Path-Bar, the search icon, the other two icons, even the close-button, and everything inbetween.

I honestly could do without dragging natilus from the Path Bar (that represents folders) and restore the functionality that is not replicated anywhere else :(
Comment 5 Carlos Soriano 2017-08-14 10:02:13 UTC
I kinda agree with reporter on bug 776663 that is inconsistent... so I don't know.

What we can do is allow dnd as a receiver, that would still allow to put files in the pathbar, but not allow to drag files from the pathbar.
Comment 6 Mario Wenzel 2017-08-14 10:13:54 UTC
I can understand that one might think that grabbing the button may be inconsistent, but it actually isn't.

From all the buttons in the top bar the items of the Path Bar are the only objects that correspond to actual "physical" objects within my computer and are not "actions".

Also, the Breadcrumb in Windows Explorer works the same way. I can drag items to it and I can move/copy the represented folder to somewhere.

Representing physical objects and have them only as buttons to interact with and not in any other way we use with nautilus' other representations of physical objects is the actual inconsistency.

If there is some object in nautilus that represents a folder, I should be able to drag a file onto it.
Comment 7 Carlos Soriano 2017-08-14 10:19:07 UTC
I'm quite impartial about it, I think both sides has similar valid arguments.

Maybe check with designers and/or with the people in the other bug report?
Comment 8 António Fernandes 2017-08-14 10:53:13 UTC
Created attachment 357544 [details] [review]
pathbar: Restore ability to act as drop target

(In reply to Carlos Soriano from comment #5)
> What we can do is allow dnd as a receiver, that would still allow to put
> files in the pathbar, but not allow to drag files from the pathbar.

Attaching a patch that restores only the receiver part.
Comment 9 Carlos Soriano 2017-08-14 11:21:23 UTC
Review of attachment 357544 [details] [review]:

This does not restore all the dnd functionality that was there before, but I actually think this would be a more suitable approach.

I have been trying to remove the "do actions when the user just moves with the mouse" for quite a while, like the so called spring folders.

So let's go with that for now.

Just a nitpick, in the commit message say explicitly that this doesn't restore the timeout handling etc.
Comment 10 António Fernandes 2017-08-14 11:30:00 UTC
(In reply to Carlos Soriano from comment #9)
> I have been trying to remove the "do actions when the user just moves with
> the mouse" for quite a while, like the so called spring folders.
>
> Just a nitpick, in the commit message say explicitly that this doesn't
> restore the timeout handling etc.

Well, for what I tested, it DOES restore that part. By hovering a pathbar button, it changes to that location after a timeout.

If I understand it correctly, the timeouts that were removed by commit d379767851ac3dc28b1108d87b60ac0cad6c4c4a were related to the pathbar slider buttons. I actually should have restored that, without which the pathbar doesn't scroll by hovering the edges while dragging, as would be the expected behavior.
Comment 11 Carlos Soriano 2017-08-14 13:41:24 UTC
ah! Wait, I need to take a deeper look then. Sorry for the confusion.
Comment 12 António Fernandes 2017-08-14 13:56:00 UTC
Created attachment 357560 [details] [review]
pathbar: Restore ability to act as drop target

This patch also restores the ability to scroll pathbar while dragging by hovering the slider buttons (the [<] [>] things on the edge of the pathbar).
Comment 13 Carlos Soriano 2017-08-16 10:00:35 UTC
Review of attachment 357560 [details] [review]:

Thanks Antonio!

However this issue it's starting to look as in we need to take a step back and see what are the use cases we need this, and make sure dnd is the right choice for those... So I'm putting on review state, since the code looks good, but we need some design input in here.
Comment 14 Carlos Soriano 2017-08-16 11:44:49 UTC
Review of attachment 357560 [details] [review]:

After discussion with Antonio on IRC, let's merge this and restore the destination dnd entirely except the changing to a different folder when hovering.
Comment 15 António Fernandes 2017-08-17 10:43:53 UTC
Created attachment 357792 [details] [review]
Revert "pathbar: Remove dnd handling"

Patch 1/2

As agreed on IRC, let's do this as a two-step change. First revert the commit that introduced the regression reported on this bug.

Second patch will remove again only the problematic drag-source handling.
Comment 16 António Fernandes 2017-08-17 10:44:59 UTC
Created attachment 357794 [details] [review]
pathbar: Remove drag-source handling

Patch 2/2
Comment 17 António Fernandes 2017-08-17 10:48:51 UTC
Note: as side effect, this also restores the "changing to a different folder when hovering" behavior, which is handled by nautilus-window-slot-dnd.c We may deal with that another time.
Comment 18 Carlos Soriano 2017-08-17 10:52:37 UTC
Review of attachment 357792 [details] [review]:

yes
Comment 19 Carlos Soriano 2017-08-17 10:53:03 UTC
Review of attachment 357794 [details] [review]:

yeah, thanks Antonio!
Comment 20 Carlos Soriano 2017-08-17 13:58:31 UTC
Attachment 357792 [details] pushed as 715a28c - Revert "pathbar: Remove dnd handling"
Attachment 357794 [details] pushed as 292f43d - pathbar: Remove drag-source handling