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 787356 - GtkPlacesSidebar: Dragged bookmarks can get inserted higher than the drawn line indicates
GtkPlacesSidebar: Dragged bookmarks can get inserted higher than the drawn li...
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: Other
3.22.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2017-09-06 11:10 UTC by Stephen
Modified: 2018-05-02 19:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gtkplacessidebar.c: move bookmark at the placeholder index (1.04 KB, patch)
2017-10-07 15:29 UTC, Nelson Benitez
none Details | Review

Description Stephen 2017-09-06 11:10:39 UTC
(Originally filed in Nautilus at https://gitlab.gnome.org/GNOME/nautilus/issues/3 ) :

Bookmarks drag and drop is back to behaving unpredictably and not reordering as intended (it seemed to be fixed for a while and working for the last couple of years, as far as I noticed at least).

For example, with the following ~/.config/gtk-3.0/bookmarks content:

file:///home/username/One  
file:///home/username/Two  
file:///home/username/Three  
file:///home/username/Four

dragging "One" to below "Four" (green insertion line appears below "Four") in e.g. Nautilus or the GTK+ file chooser results in the following ordering:

Two
Three
One
Four
Comment 1 Daniel Boles 2017-09-06 11:36:31 UTC
(In reply to Stephen from comment #0)
> Two
> Three
> One
> Four

observation: That's descending by name. So I instantly think of bug 787100...

What about other/more elaborate sets of names? Is there any consistent pattern?
Comment 2 Stephen 2017-09-06 11:55:49 UTC
(In reply to Daniel Boles from comment #1)
> 
> observation: That's descending by name. So I instantly think of bug 787100...

True, but coincidental.

Actually, I've figured out the exact behaviour:

Releasing the item when the exact cursor location (i.e. where the end of a normal mouse arrow *would* be) is *below* the displayed green line "drop location" puts the item in the correct place.

Releasing when the cursor is *above* the green line puts it one position too high.

In other words, the grabbed item is positioned *above* whatever item it is over, *not* where the green line is shown.

This suggests the line drawing logic/code is entirely separate from the "move item to" logic/code. It should be shared!!
Comment 3 Nelson Benitez 2017-10-07 15:29:39 UTC
Created attachment 361093 [details] [review]
gtkplacessidebar.c: move bookmark at the placeholder index

As that index is set in drag_motion_callback() and visually shown
on the widget as a drop target hint.

--------------

Fix for the bug.
Comment 4 Nelson Benitez 2017-10-07 15:35:43 UTC
Changed component to "widget: other" as this bug is in GtkPlacesSidebar not in GtkFileChooser.
Comment 5 GNOME Infrastructure Team 2018-05-02 19:04:06 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/904.