GNOME Bugzilla – Bug 132682
Auto-scroll in treeview
Last modified: 2018-04-15 00:22:08 UTC
If I click on an item in a tree view (for example a file name in the new file chooser) and drag the mouse cursor down below the treeview, I would expect the view to start scrolling. The old file selector does this. Emacs text buffers do. Mozilla's main frames do. Mozilla's file selector curiously does not.
Does this even make sense outside the context of a drag-and-drop operation? (GtkFileSelection doesn't do that, btw)
Actually, in 1.x the file selector did do that. There is no end to apps doing this. I just noticed it in purify (which probably means in motif) and in a java app here. Reclassifying as enhancement.
(In reply to comment #1) > Does this even make sense outside the context of a drag-and-drop > operation? > > (GtkFileSelection doesn't do that, btw) I think that auto scroll would apply when the treeview is neither draggable nor droppable, as a part of multiple select. From what I've been reading "rubber banding" is a keyword that might be useful, but that concept appears to have been abandoned in the treeview context some time between 2.0 and 2.6
I also think that this works with the rubberbanding API in GtkTreeView.
the current behavior is that when dragging the row to the border of the bin window, the treeview starts to scroll. However, the scrolling stops when the row is dragged below the bin window of the treeview. I have made a patch to do the following: when the treeview is 'reorderable', the dragging of a row down the treeview widget, the scrolling of the treeview continues. This is possible because the destination of the drag can only be the source treeview itself. Therefore, there is no ambiguity of the destination of the drop. when the treeview is _not_ 'reorderable', the dragging of a row to the border of the bin window of any treeview widget starts scrolling of that treewindow. However, as soon as the drag is outside the bin window area, the scrolling stops. This is logically, because it is not sure what will be the destination of the drag. The patch is implemented on top of another patch I created before (71926). The patch is clearly indicated by "bug 132682" and "bug 132682 - end" comments
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new