GNOME Bugzilla – Bug 624292
Drag and dropped file at the end of a playlist is misplaced if the playlist takes the full height of the window
Last modified: 2012-08-20 18:37:12 UTC
Hi ! Short form : When adding a file at the end of the playlist, by drag'n'drop, the file is misplaced if the playlist has a vertical scrollbar. Long form ; in the following conditions : - if the playlist already takes up the whole height of the window (thus, has a scrollbar) - and if one or several files are drag and dropped after the last file of the playlist -> expected behaviour : the D&D'ed file should be the last file of the playlist -> obtained behaviour : the D&D'ed file is misplaced, just before the last file of the playlist The issue is 100% reproducible here. Ubuntun 10.04, Totem 2.30.2. Cheers !
Hi Bug confirmed, 100% reproducible. In totem_playlist_add_one_mrl (file totem-playlist.c) function gtk_list_store_insert_with_values is used. I debug this part of the code and the argument pos (showing the position of a new song on the list) is valid during the reproduction of error. Maybe problem is in the same function gtk_list_store_insert_with_values. Best Regards
Created attachment 167518 [details] [review] Improved condition of adding the last element to the list. The problem exists in a condition of adding the last element to the list (functions: gtk_list_store_insert_with_values and gtk_list_store_insert_with_valuesv, file gtkliststore.c, package libgtk2.0-dev).
Rafal, if this is a GTK+ bug, you should file it against GTK+, explain the changes you're making, and create a git formatted patch.
Please ignore my last comment. The arrangement of elements on the list is good. The problem is the location of the newly added file in terms of dropping it in the file list, and exactly which in part of the file on list has been dropped (GTK_TREE_VIEW_DROP_BEFORE, GTK_TREE_VIEW_DROP_AFTER). Even if gtk_tree_view_get_path_at_pos function() sets the pointer of library->priv->drop_pos on GTK_TREE_VIEW_DROP_AFTER, the file is placed before current file in the list.
*** Bug 658736 has been marked as a duplicate of this bug. ***
Tentatively moving to GTK+ then. If it helps, see my comments on the two parts of the problem on duplicate bug 658736. Rafal, would you create the patch as Bastien asked? Thanks! ;-)
Hm, Totem does weird things in totem-playlist.c about the order of files, so that may well be a bug there. I'll try changing this when I get my disk back, leaving here for reference. for (i = 0; list[i] != NULL; i++) { /* We get the list in the wrong order here, * so when we insert the files at the same position * in the tree, they are in the right order.*/ file_list = g_list_prepend (file_list, list[i]); } if (file_list == NULL) { gtk_drag_finish (context, FALSE, FALSE, _time); return; } playlist->priv->tree_path = gtk_tree_path_new (); gtk_tree_view_get_dest_row_at_pos (GTK_TREE_VIEW (playlist->priv->treeview), x, y, &playlist->priv->tree_path, &playlist->priv->drop_pos); /* But we reverse the list if we don't have any items in the * list, as we insert new items at the end */ if (playlist->priv->tree_path == NULL) file_list = g_list_reverse (file_list);
Was a bug in Totem all along, fixed now. *** This bug has been marked as a duplicate of bug 663951 ***