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 658736 - Dragging a file to the playlist pretends inserting it in the middle when it goes to the bottom
Dragging a file to the playlist pretends inserting it in the middle when it g...
Status: RESOLVED DUPLICATE of bug 624292
Product: totem
Classification: Core
Component: general
3.0.x
Other Linux
: Normal normal
: ---
Assigned To: General Totem maintainer(s)
General Totem maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2011-09-11 10:50 UTC by Milan Bouchet-Valat
Modified: 2011-09-12 15:59 UTC
See Also:
GNOME target: ---
GNOME version: 2.91/3.0



Description Milan Bouchet-Valat 2011-09-11 10:50:48 UTC
If you drag a file to a playlist that already contains files, a bar is drawn at the place the mouse pointer is, seemingly indicating the file will be inserted at this place if you drop it. But if you do it, the file goes to the end of the list.

I can understand the rationale for this behavior: most of the time, you want to add files to the end of the list, and there's no easy drop target for that if there are enough files to fill the tree view. Fine. But in that case, the playlist shouldn't have a bar under the pointer. I'm not sure what the intended behavior is, but it should be consistent with the UI indications.
Comment 1 Milan Bouchet-Valat 2011-09-11 10:59:26 UTC
I've just managed to debug another weird issue that turns out to be related, so I'm adding it here. When you drag and drop several files to the blank area of the tree view, they're added in the correct order (alphabetical). If you drop them in a place where there are files (i.e. the horizontal bar is shown), they're added in the reverse order.

This is made more annoying by the fact that, if the tree view is filled with files, you necessarily hit that bug. Because of this, the sorting behavior is reversed at some point without any apparent reason, which is very disturbing.

Looks like there's something wrong with the insert process then, which is why both issues seem to be related.
Comment 2 Bastien Nocera 2011-09-12 15:54:53 UTC
Likely a dupe of bug 624292.
Comment 3 Milan Bouchet-Valat 2011-09-12 15:59:34 UTC
Indeed, thanks!

*** This bug has been marked as a duplicate of bug 624292 ***